I think this needs some nuance - this is definitely true in some domains.

Most of the domains I worked in it was the other way around: using an ORM didn’t mean we could skip learning SQL, it added an additional thing to learn and consider.

In the last years writing SQLAlchemy or Django ORM the teams I was on would write queries in SQL and then spend the rest of the day trying to make the ORM reproduce it. At some point it became clear how silly that was and we stopped using the ORMs.

Maybe it’s got to do with aggregate-heavy domains (I particularly remember windowing aggregates being a pain in SQLAlchemy?), or large datasets (again memory: a 50-terabyte Postgres machine, the db would go down if an ORM generated anything that scanned the heap of the big data tables), or highly concurrent workloads where careful use of select for update was used.

> In the last years writing SQLAlchemy or Django ORM the teams I was on would write queries in SQL and then spend the rest of the day trying to make the ORM reproduce it.

Ah yes, good times! Not Django for me but similar general idea. I'm not a big fan of ORMs: give me a type safe query and I'm happy!