An ORM at the basic level just populates some data structure (could be a hash map) from your database.

At some point when an app gets complex programmers tend to keep SQL organized so it's not all throughout the code, just like keeping view logic separate. To me that is just a simple ORM as well.

There seems to be an anti-ORM trend but I suspect it's more of an opposition to certain established ORMs that are really complicated to work with.

If that's not true, I'm also curious to hear about other strategies that people are using these days. Having no strategy at all seems a little sloppy to me, but I'm always open to new ideas.

ORMs either arise from need (homegrown) or are bought with way more features than you need and the associated complexity that brings.

If there were a way to scale an ORM so it can modularly add features/complexity as you need it (ie, customize the metamodel complexity), that would be the most ideal approach.

On the other hand, testing thousands to millions of possible use cases in combined codebases is a nightmare.

I agree. I've written many home-grown ORMs as well as used a few well-known ones. It's definitely easier in some ways writing your own because you understand all of the details & it has nothing in it that is unneeded. The downside is that you don't have the community support maintaining the code and providing support resources. On the flip-side I've spent days researching and tweaking hibernate mapping files, occasionally making me want to throw my laptop out the window!

One thing is for sure, no matter what ORM or similar solution you use, if you don't know how to observe and understand the SQL that is generated then you won't be able to use it efficiently.