My experience is that ORMs are like training wheels for fledgling teams/developers. They're a fantastic way to make sure everyone is following the same pattern/rules and that changes will more-or-less work over time without too much headache. If you have a team with developers who are actually skilled in SQL and use things like Dapper when writing code, you will actively detest the notion that the raw SQL should be abstracted away.
I also believe that you are more likely to completely go off rails if constrained at domain modeling time into an ORM-compatible schema. The real world usually has some cranky things like circular dependencies and self-joins. Modeling these effectively with an ORM can be a nightmare (in my experience). If you have access to SQL, determining how to manage a circular dependency is much more obvious & direct. The effect is that you are free to model you domain in such a manner that it more closely resembles actual reality. In turn, this makes it easier to talk about and write the SQL.
There is 100% a virtuous cycle here. The more you force yourself to endure the SQL, the better every aspect around it will become. You will feel the fire of a bad schema the moment you see if it you have been spending thousands of hours troubleshooting queries over bad schemas. Knowing when an arrangement of tables is "smelly" before they see any data can save you so much frustration. I think a lot of people who hide from SQL aren't hiding from SQL. They're hiding from someone else's horrible interpretation of a problem domain.
I still don't get it, none of what you mention is impossible or even difficult in many ORMs (at least none of the ones I've used), and using ORMs != being unskilled in SQL. I've had many cases where I start with the SQL, optimize it and then convert it to ORM to take advantage of not having hardcoded columns in my code for example. I've also done the reverse, converting ORM syntax into raw SQL (still sing the ORM), and I've also written ORM free apps. In my experience, using ORM makes collaboration much easier, especially if it helps take advantage of statically types languages.
I think there is this obsession by engineers to signal skills/experience, where everything that looks like it may also make it easier for less experienced developers must be bad or a result of some useless trend. However, we don't need to litter our app with SQL literals to show how skilled we are. I was part of a team once where one of the developers made it a point to do this because ORMs are for losers, and surprise, most of the bugs were things like changing column names and not updating related queries, plus insufficient testing because "we're moving fast!". Even if it did not cause bugs, isn't it a lot more effort than having one place you need to change?
I think we're hired to build products and solve problems, our egos should really get out of our way.
> I still don't get it, none of what you mention is impossible or even difficult in many ORMs
You may have not had to deal with cycles in data or other unusual views over the object graph that were not originally intended. Again, its not that you can't solve the problem using an ORM, its that its an opinionated way to solve a problem that constrains your design choices in such a way that you now have less fidelity at domain modeling time, which may result in yucky SQL down the road. ORMs effectively remove SQL capabilities from your tool belt. Yes - There are always hackarouds, but for most teams these "soft" limits are effectively hard ones and lead to bad career/product outcomes.
> using ORMs != being unskilled in SQL
Not necessarily, but I've personally never seen a developer go from writing CTEs in Dapper back to writing POCOs and using Entity Framework.
> I think we're hired to build products and solve problems, our egos should really get out of our way.
This is literally what the "stop using ORMs" crowd has been trying to sell as well. SQL has been the answer for half a century now. If you actually managed to kill your ego, you'd try to fit everything in that box as tightly as possible.
idk, this sounds a lot like don't use an IDE, use vim/notepad because IDEs can be opinionated. Maybe we've had different experiences, but I just think a lot of these arguments are unreasonably absolutist. Granted, some IDEs are terrible, but there's a sweet spot and many older IDEs have learned from it. I think ORMs have matured in this direction as well.
I also believe that you are more likely to completely go off rails if constrained at domain modeling time into an ORM-compatible schema. The real world usually has some cranky things like circular dependencies and self-joins. Modeling these effectively with an ORM can be a nightmare (in my experience). If you have access to SQL, determining how to manage a circular dependency is much more obvious & direct. The effect is that you are free to model you domain in such a manner that it more closely resembles actual reality. In turn, this makes it easier to talk about and write the SQL.
There is 100% a virtuous cycle here. The more you force yourself to endure the SQL, the better every aspect around it will become. You will feel the fire of a bad schema the moment you see if it you have been spending thousands of hours troubleshooting queries over bad schemas. Knowing when an arrangement of tables is "smelly" before they see any data can save you so much frustration. I think a lot of people who hide from SQL aren't hiding from SQL. They're hiding from someone else's horrible interpretation of a problem domain.