Nonsense. Everything is overridable. ORMs are perfect for a whole lot of standard cases and nobody prevents you from writing SQL code for custom cases and performance improvements.
In my experience this article is spot on. It's easy to say "oh sure just use custom sql for this edge case" Only those edge cases turn out to be increasingly common and it is increasingly hard to work with data that may be coming at you in multiple formats.
And if you understand the types of queries being done under the hood by your ORM then sometimes using a custom query to retrieve ids to be used in a simpler ORM query is not such a bad idea. I think it's a case of doing things consistently in your code base so you use your ORM when it helps you and don't fight it when it's not going to help you.
The other existing solution provided by the author is to switch to a key-value datastore, which still would not solve your problem.
I've done this several times using Django's ORM.
Really, there are good and bad ORMs. Bad ORMs produce the results you mention. Good ones are much more adaptable.
Maybe the gp doesn't know about it or chooses not to use it, but it exists.