I think the problem with ORM is that at the end it is only a wrapper over SQL, say like Winzip is for Zip. So while it may look pretty and easy to use, it always has to obey the rules of the host program, and so workarounds such as these have to be invented.
On the other hand if somehow ORM was part of the core compiler AND database, then somehow it could be possible that even when you write a for loop on the top and have an if conditions inside the block, or perform a join, the compiler understands it and pre-compiles your code without needing such workarounds (as there aren't two separate layers to join). So you would treat objects and objects and never have to worry about how the wrapper is being generated or what kind of indexes or queries it will run finally. I'm not an expert at compilers though but for strictly typed languages it could be possible.
That would never work though, at least not in the perfect, non leaky way the author and you would like. When you have a loop, even if the database could somehow understand that loop, you can put anything inside it. You could make a call to an outside service, write to disk, etc. With a single SQL query the database can take it and optimize it since it has a full understanding of its data domain.
On the other hand if somehow ORM was part of the core compiler AND database, then somehow it could be possible that even when you write a for loop on the top and have an if conditions inside the block, or perform a join, the compiler understands it and pre-compiles your code without needing such workarounds (as there aren't two separate layers to join). So you would treat objects and objects and never have to worry about how the wrapper is being generated or what kind of indexes or queries it will run finally. I'm not an expert at compilers though but for strictly typed languages it could be possible.