Not all ORMs are like hibernate and gorm.
I'm author of a lightweight ORM for Go and Scylla / Cassandra [1] so I may be biased.
In my view use of a good ORM makes your code more resilient to change, refactorings are simple and stupid mistakes largely eliminated.
A benchmark of usefulness of an ORM can be how many lines need to be changed to add a new field to a struct / class.
In a good ORM this should be about 1, it should still work be ~1 if you use a hand crafted SQL / CQL.
The worst thing that ORMs try to do is handling relations (eager / lazy loading) and handling sessions / object lifetime. This is mainly because it's impossible to have one-fit-all solution for all usecases even in one application.
I use a lot of raw sql and I also use ORMs. I don't see ORMs as being the issue the author thinks it is, bit rather that developers suck at designing the data layer. A half decent design will do as you say; it will allow the use of an ORM or hand written sql. ORMs make magic easier, and pulling that magic apart is a real pain, but so is working with triggers and stored procs. The problem exists on both sides. The solution isn't to get rid of ORMs, but to train developers in better system design.
The worst thing that ORMs try to do is handling relations (eager / lazy loading) and handling sessions / object lifetime. This is mainly because it's impossible to have one-fit-all solution for all usecases even in one application.
[1] https://github.com/scylladb/gocqlx