Sorry for the burn, but you managed to contradict yourself mid writting (or maybe you used an AI that messed up your point?)

>Raw SQL is great for simple queries, but gets old quick when you are dealing with "higher order" parameterized queries (...)

>The sweet spot is an ORM that embraces dropping down into raw SQL where needed {...)

So basically you said that ORM are great only for the sweet spot of "mildy complex query". Because Raw SQL is great for simple query, and can be invoked when the ORM is not enough for highly complex query.

So I'd stick with my strategy of mastering raw SQL. I never felt the need of switching tool specifically for mildy difficult query. These are usually boring repetitive stuff than you can usually abstract away with a stored procedure (or in a external parametrized SQL script if your development guideline is to avoid storing any business logic in the database)

PS : But of course ORM is still very relevant if your application aim to be compatible with different database vendors and you are ok to never optimize query yourself directly beyond what your ORM vendor can provide.

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.