I've yet to see a good one.
Often ORMs fail to implement JOINs efficiently.
Every ORM fails to give you a powerful query language: if they had a powerful query language, someone would write an ORM for the ORM, because the reason ORMs exist is that "SQL is hard", as the doll says, and any powerful query language will get the same treatment. But SQL is not really hard, and not having SQL eventually means you pay a huge price.
And then there's things like LDAP, which are absolutely awful. LDAP's object naming scheme has no canonical text representation. Let that sink in. And that's not even the main problem -- forcing your database to be hierarchical and a collection of objects, with no standard relation/pointer type, is. (Yes, Active Directory has an Object DN type, I'm aware.)
Just say NO to ORMs.
It's not true that people who know SQL always prefer using it to using an ORM. In one of my prior jobs we had strict controls on the queries that ran in production for performance reasons. We screened all of the query plans the planner generated, but we also used an ORM. Sometimes we needed to work around or even reimplement the queries that used to be in SQL due to niche features like index hinting or the HAVING clause. And yet usually we used the ORM because it was more concise and reduced manual mapping of columns to fields.
[1]: https://en.wikipedia.org/wiki/Object-relational_impedance_mi...
There's a really bad trend in the industry of choosing libraries or tools based on trying to improve your resume, rather than trying to find the best solution to a problem.