Delete Stale Template Caches tasks much larger in Production than Staging
First, this is perfectly normal. :) 

Have a look at Brandons explanation here on how the cache tag works.


  If the element was added or modified, it queues up a new “Delete Stale
  Template Caches” task, which cycles through the templatecachecriteria
  table to see if there are any cached element queries which (if not
  cached) would have started showing the just-saved element. If the
  query returns the element, its corresponding cache will be deleted.


So, the number of steps corresponds to the number of rows in the templatecachecriteria table in the database. 

Why would this be different between staging and production? Probably because you're getting different kind of traffic on the production site than the staging site. 

It's important to understand that the cache is tied to the url, so mydomain.com/news and mydomain.com/news?id=212 will result in two different caches being created in the database, and a number of rows in the templatecachecriteria table being created based on the number of criterias created inside the cached code (which can be alot).

The example given above is an example that we encounter a lot, where when an old site is replaced by a new one, there will still be a lot of links pointing to the new one. If these aren't handled correctly by either rewriting them to new url's, or returning 404's, this could result in many old urls generating new caches for the same page. 

The recommended way to avoid this is to use the globally keyword, and using the request path as the key, see the example in the "using key" section of the docs for {% cache %}. 

Another common caveat is that there are caches on the 404 page that is not declared as globally, for instance a menu that needs a selected state or something. Then all urls that results in a 404 not found page, will create new caches with new criterias in templatecachecriteria. I've seen examples where this will eventually just kill the server because of the number of criterias that are rerun when an entry is saved.

If I were you I'd have a look in the templatecaches table, and look at the path column to identify the paths of the created caches. This will often reveal groups of urls which generates more caches than they ideally should, and you could work from there to reduce the number.