I don't have a lot of experience with projects that use ORMs, but from what I've seen it's usually not worth it. They tend to make developers lazy and create things where every query fetches half the database when they only need one or two columns from a single row.

the problem with ORM is that some people go all in on it and ignore pure SQL completely.

In reality ORM only works well for somewhat simple queries and structures, but at some times you will have to write your own queries in SQL. But then you have some bonus complexity, that comes from 2 different things filling the same niche. It's still worth it, but there is no free cake.

I used to use ORMs because they made switching between local dev DBs ( like SQLLite, or Postgres) and production DBs usually painless. Especially for Ruby/Sinatra/Rails since we were writing the model queries in another abstraction. It meant we didn’t have to think as much about joins and all that stuff. Until the performance went to shit and you had to work out why.

My standard for an orm is that if it's doing something wrong or I need to do something special that it's trivial to move it aside and either use plain SQL or it's SQL generator myself.

In production code, plain SQL strings are a concern for me since they're subject to the whole array of human errors and vulnerabilities.

Something like stmt = select(users).where(users.c.name == 'somename') is basically as flexible as the string, but it's not going to forget a quote or neglect to use SQL escaping or parametrize the query.

And sometimes you just need it to get out of the way because your query is reaaaaaal weird, although at that point a view you wrap with the orm might be better.

If you've done things right though, most of the time you'll be doing simple primary key lookups and joins with a few filters at most.