I imagine that tons of their user base (especially for small hobby sites that only occasionally, if ever, see high traffic or run background tasks) look for this, and yet there's nothing pointing to it other than old posts on the mailing list. At least put information and resources for autoscaling in the Docs section of the site.
Acquiring resources only as long as you need them, and then releasing them when you're done, should be the standard service - complete user control should be the advanced feature set. They already do this for websites on a single dyno: they spin them down when they're idle for a while. But they don't do it with workers (what effect does the latency of starting a backup job up really have? it's already running in the background).
But my question stands: why isn't this stuff very visible - i.e., on Heroku's DJ doc page: http://docs.heroku.com/delayed-job , or at least linked from there? Or published as an official piece of code on the Heroku github page?
I'd certainly be happier paying more per pro-rated unit of time that I actually use than I am feeling as though I'm in an arms race to not be fleeced.
Is there really that much revenue to skim off the top? Either way, they're paying Amazon out of those charges.
But I'm not so cynical as to think that their success is reliant on this income.
I'd be extremely surprised if Heroku actually spools up EC2 instances the moment you move the slider. It'd be a far more intelligent (and profitable) design to simply make sure there are sufficient resources to maintain the desired service levels with a buffer to deal with spikes in demand.
It should be relatively straightforward to provide service levels that are functionally identical to actually starting each "dyno" or "worker" with a greatly reduced cost structure.
Relying on customers overspending due to technical deficiency seems like a pretty poor business model.
I didn't mean to say they're relying on it, simply that it's adding to the bottom line and it would be greatly missed.