A more traditional approach of 1 web and 1 db server (possibly even physical boxes) might end up providing better value and give him enough time to figure out how to scale this horizontally on EC2 (the web part should be easy...remove any in memory state data, the db might be a bit more work).
Even a small machine can trivially handle 150k pageviews per hour, even with ruby strapped around its neck.
Spiky traffic is an issue of its own, but it sounds like Mark's site is growing fairly steadily (albeit steeply).
I agree with latch that heroku becomes (ridiculously) overpriced the further you depart from the free plan. If a stopgap is urgently needed then it may of course still be a valid choice. But in the midterm, if you're pushing serious traffic, look elsewhere.
I have yet to use them at higher loads. We shall see.
Also, it's my understanding that they're still less expensive than something like EngineYard, and still generally cheaper than paying for a sysadmin. Dedicated hardware will of course outperform any of this stuff, but I also don't have to think about it at all. Even VPSes involve spending initial setup time and then periods of upkeep, you can't just install and say "done."
Then again, I'm coming from a mostly theoretical standpoint. I don't have real world experience at true scale.
With regard to heroku you have a point about the "not needing a sysadmin" part. That, however, only works for a fairly short period during the lifecycle of a business; heroku is ideal for bootstrapping.
Once your site grows to the scale that mark is seeing (if that persists, which I doubt) then the heroku value proposition rapidly shrinks.
At that point you start to need more customization than heroku can provide [for a reasonable price] and you also need at least one person with systems knowledge in your company to prevent expensive mistakes in the software architecture.
Gladly that person will then more or less pay for itself, simply by moving the app to a cheaper hosting platform.