After more than 10 years using those ORMs at work, in DotNet/Java worlds, my current opinion on that topic:
-the only project where ORM was worth was a simple backend admin project with many tables and very little load: ORM avoids having to write tedious simple CRUD queries.
-for recruiters, it feels more simple to find people with language X than to find people with language X + SQL.
OK but ...
-to understand the intricacies of ORMs takes a lot of time and effort, probably as much if not more as writing proper SQL.
-illustration of the previous point: it is hard to know the amount of data the ORM is really carrying, hence the common situation where half of your DB ends up in memory.
-developers tend to forget performance improvements. For instance, in C#, IQueryable objects are used everywhere, meaning that in any layer of your app, the query that will be pushed to your server might be modified: hard to tweak your performance in such context. More generally, this additional layer makes everybody postpone the time when you have to think about DB performance.
-it prevents you to use advanced DB features (ex.: built-in audit trailig and versioning), either because nobody ends up knowing SQL DB anymore, or because ORM makes it harder if not impossible.
-queries sent by the ORM to the DB seem always huge and be returning more than they should.
-for performance or complicated requests, you always end up adding some SQL to your ORM.
-because of the previous point, the maintenance advantage of ORM, namely being able to automatically migrate your DB with your code is lost: you end up having to maintain more or less manually some SQL.
-letting the ORM automatically update the SQL DB during migration on real data always make people sweat: if any problem occurs during that process, welcome in hell. I feel always more comfortable being able to write some SQL fix in worse case.
-for my side projects, I never use ORM, and enjoy it.