ORM is most supposed to save you from repeating the same load-db-put-data-into-objects over and over. It is also supposed to do caching and other similar optimizations for you.
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.
If texts and lists were easy to use, nobody would have invented structures, objects and the other thousands of abstractions available on modern languages.
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.
Of course, there's things like SQLAlchemy Core which give you a lot of the syntax of an ORM for building dynamic, complex queries (no more gluing strings together when the shape of your query is dynamic), while returning proper cursors which return arrays and dictionaries.
In an indie game's development that I'm familiar with they use to use an orm or something similar but switched to manual SQL after the orm was generating way too many redundant statements. realtime mmorpg
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.