I think the point they were trying to make is for using ORM for everything until you need a query complex enough or performant enough to drop back to a raw SQL layer.

That's the pattern I've seen the most with ORM setups these days. That or dropping performance heavy sql into stored procedures but in the end it's all a matrix of ease of use/maintainability in some scenarios vs full control and performance tuning and what makes sense for that use case.

Then please forgive I was triggered on their introductory expression "Raw SQL is great for simple queries, (...)"

I understand your point but I'm not sure it's efficiency to use an ORM that abstract the easy stuff away from the programmer but rely on expert level knowledge to solve what remain. Because at this point the developer that build everything with an ORM will either: - Face complexs SQL query that he'll have to build from the ground up by summoning expert SQL skills they probably haven't use for a while - Seek external help from an SQL expert than doesn't know how the system was build in the first place*

If you know you'll need database specific SQL optimizations on complex query in the end, I guess using SQL everywhere could also make sense. Same language and code logic from simple to complex query and a complexity gradient in between.

*I guess same point could be made about vibe coding actually.