Data never goes out of fashion, it's easy to use, it's usually text, and it's usually returned in convenient lists.
If you want to select a gazmillion rows, you're probably doing something wrong if you're doing it with an ORM.
The overhead of storing all that metadata and the object structure overhead for each row would make it a poor choice for massive volumes.
Caching results from a database seems a bit pointless to me, since databases do that already anyway.
Rather figure out how to optimize your SQL so that you don't have to build a cache. The database is almost never the bottleneck with well-written SQL.
An ORM will give you a description of the database you can use by reflection, and an abstraction layer that avoids using hard to use lists and tables. The first one is way more usefull than the later, but both are good things.
Also, application servers are normaly much more numerous than database servers, and much easier to scale up. Thus, anything that offloads work from the database to the application will simplify your environment when you grow.
If we insist on it, SQL itself was supposed to smooth over differences in db implementation. Ehm.
If all you need in one query, then figuring out how to make ORM running may be waste of time. If you need gazimilion of them and you need results cached reasonably and so on and so forth, ORM starts being very useful.