My main argument for ORMs is the mapping between SQL columns and your data model; having to write out SQL and code to load an SQL result set into your data model feels like a lot of duplication. And it gets a lot more difficult when you have more complicated data models spanning multiple database columns - that is, if your data model is like a document that has to be inserted and updated into a set of normalized database tables.
That said, if that wasn't as much of an issue, or if I still had the patience and typing skills to write a lot of boring code, I wouldn't object too much. I'd also treat SQL as a first class citizen, so dedicated .sql files that the application will load or embed and use. That way, the SQL can be developed, maintained and run outside of the context of your application - editors can execute them directly to a (local) development database.
What if your SQL is your data model? I believe object-oriented design is forcing us to do a lot of duplication for very little gains, just like it did on game design and the industry started moving towards data-oriented design and entity-component system.
The sooner we move away from the big lie that is DDD, the more productive we can be.
Agreed, lots of comments here saying that people don't want to learn SQL, I don't buy that argument. I think most people already know SQL because at some point it's inevitable, and it's also not that hard.
The value of the ORM is what the name implies: mapping your data from rows into something convenient to use in your language.
What people are really complaining about is ORMs that needlessly try to re-invent SQL, but they don't all do this. Someone else brought up Ecto, it's a brilliant ORM because the resulting SQL is always obvious.
That said, if that wasn't as much of an issue, or if I still had the patience and typing skills to write a lot of boring code, I wouldn't object too much. I'd also treat SQL as a first class citizen, so dedicated .sql files that the application will load or embed and use. That way, the SQL can be developed, maintained and run outside of the context of your application - editors can execute them directly to a (local) development database.