[munk-a]

ORMs, when best used (and we use them even though we're pretty SQL literate and maintain a lot of SQL) will survive forever, nothing beats an ORM for really dirt simple expressions that you want to be trivially testable. Never in my life do I want to see someone write an UPDATE query against a single table with no shenanigans with dynamic field support using string gluing to properly stitch in all the columns - this is something a known tool can do better, this is a great opportunity for an ORM.

A non-great opportunity for an ORM is anything I'd call a "report query" (some complex read-only query involving a lot of JOINs, a bunch of WHERE clauses and possibly some nested aggregation for funsies) - this is where you pull out the SQL (or alternative query language!) because an ORM will struggle to properly support all the functionality you need and because trying to tune a query being produced by an ORM (even just to make sure it's well aligned with logical indices) is a task that yields nothing but endless frustration.

[Scarbutt]

Never in my life do I want to see someone write an UPDATE query against a single table with no shenanigans with dynamic field support using string gluing to properly stitch in all the columns

These are just convenient features that most ORMs provide and can exist entirely outside of ORMs, they are not the primary purpose of ORMs.

[munk-a]

You are correct by their design. But by usage I've found that to be by far the most valuable thing that ORMs deliver. Making use of ORMs to power an ActiveRecord system in your codebase has only ever, to my observation, lead to pain. Querybuilders that are equipped with more advanced functionality around type security and response decoding are quite a valuable tool.