It's talking about optimizing something that takes less than 1% of the vast majority of an application's cycles. Which doesn't really mean anything... Be careful using this sort of benchmark to disproportionately affect decision making.
I think we'd agree that yes, Model instantiation most likely doesn't matter.
On the other hand, Model materializaion and query-interfaces most certainly DO.
In fact, in your _average_ Ruby Web Application, there's a good chance that the O/RM and template rendering makes up the vast majority of your request time.
Not database calls. Not controller logic. Only the Ruby side of O/RM interaction and rendering templates.
It's impressive that 37Signals has gotten most requests to process in under 50ms for Basecamp Next.
The truth though, that you frankly don't hear often enough, is that that's not exactly any great accomplishment for many languages/frameworks. I've worked on ASP3 and ASP.NET applications that had the same performance using hardware that was easily five times slower than anything you could buy today. The kicker is that that kind of performance came with entirely uncached pages delivering hundreds and oftentimes thousands of rows of financial reports.
Back to basics, if you want it fast, it's a good bet that a simple DAL using Sequel Datasets is going to outperform just about anything else. Skip the models when all you're doing is dumping data for display.
After that, see what you can do about limiting interpolation and String instantiation in your templates. That's where all your Template time is going.
It's something you can build in a little bit at a time, and worrying about 5% here, and 20% there definitely will add up.
What takes the other 99%? Did you measure?
At least in my own apps. Model instantiation being a bottle neck practically implies that you generate models in a tight loop and do nothing else with them, such as persisting them.