Instead of polarizing between massive native queries in ORM strings vs DB-specific imperative stored procedures I would suggest a middle ground which are table VIEWs [0]. They are trivial to design (just SELECTs), stay declarative like tables, can be materialized for efficiency [1]. Finally they can be easily handled in ORMs as both static and dynamic entities, with all read-only benefits, with no need of any non-standard mapping or native queries.
This is an excellent point. I don't get the polarised nature of the debate to be honest - there is room for all approaches in a "best tool for the job" way. I use EF Core a lot in my work, and it's the first tool I reach for, and if I need a view, then I use a view (EF Core has fantastic first-class support for these nowadays). For everything else there is Dapper.
I think a large part of the problem here is that developers who learn to leverage a database only through an ORM are missing out, and really they should also learn SQL (literally the only part of the article that is still objectively correct is the author's advice to learn SQL) to gain a better understanding of when (and when not) to use an ORM. Every other complaint in the article is either classic misuse of the ORM, or else a shortcoming of the ORM in question.
[0] https://www.postgresql.org/docs/current/sql-createview.html
[1] https://www.postgresql.org/docs/current/rules-materializedvi...