Earlier quoted context omitted.
I think the first objection one would raise is that you don't need an ORM at all. It all depends on the application, of course, but ORM means giving up a lot of control (and transparency, and understanding) of your database in exchange for a few shortcuts regarding things like M:M links.
IMO, if you're using an ORM because you want many-to-many to work in a neat way, then you're using an ORM for the wrong reasons. Use an ORM because tools like this: https://marshmallow.readthedocs.io/en/latest/ work really well with it. And tools for migrations: https://sqlalchemy-migrate.readthedocs.io/en/latest/ start to make sense in your code. You don't need an ORM to do either of those things, but it makes thing…
No, it's a matter of philosophy. The newbie who has learned to code without ever being taught SQL, and the employee of an "agile" app sweatshop who doesn't care about the quality of his code or data, may prefer ORM for its' quick-and-dirtiness, or may use it by default because he knows no better way. I'm not saying that's wrong, but, there are other philosophies. There is the whole "craftsmanship" idea out there, that we should actually care about making things well. Jobs and Wozniak for example supposedly were adamant that the insides of Apple computers were designed well. If you care about your database and want to use special features like triggers, procedures, recursive queries in Postgres, etc., then ORM is about as helpful as clamshell packaging.