That's assuming changing the schema is just about changing the layout of the database, which is definitly not true.
You have your code depending on it, documentation, constrainsts, replication, caching, db load, deployement systems, different envs and versions...
The SQL is the easy part and barely registers as an issue.
I see the same problem with SQL lovers rejecting ORMs as a dumb way to avoid using the right tool for the job.
But using an ORM is not about avoiding to write SQL. It's about all the rest: code introspection, data validation, documententation, having a common api, tooling, etc
ORM are frameworks that exist mainly as a way to avoid writing and maintaining thousands of lines of boilerplate.
Like most frameworks (i.e. packages that force you to write your code to conform to their patterns) a really good one confers a massive boost in productivity while a really bad one is horrifying to work - it fails in bizarre unexplainable ways and straitjackets your development.
IME, passionate rejection of ORMs predominantly comes from people who have been scarred by experience with really bad ORMs.
For example JPOX was an ORM that almost put me off the entire idea. It was horrendous.
Recently I've used Django ORM and SQLAlchemy - both are warty but generally decent and better than not using any ORM.
This is somewhat language dependent - certain language qualities inhibit the creation of decent ORMs (e.g. it's not really possible to create a decent ORM in golang due to its design).
I've had bad luck with ORMs in general, mainly because they fall apart whenever I need to do something complicated. The abstraction is just too leaky.
However, I've had really good luck with Doobie, a purely functional SQL library in Scala. The big difference is that queries can be manipulated as ordinary pure values, which really lets you do some cool stuff. I actually used these features to significantly speed up a schema change in a large database I was working on.
That's something I don't understand as well. There is no need to go 100% SQL or 100% ORM. You can use raw SQL with the ORM, and the good ones have actually features to make it easy and productive. You don't even need to use the OOP nature of ORM for querying, good ones will have a functional layer for those as well.
You have your code depending on it, documentation, constrainsts, replication, caching, db load, deployement systems, different envs and versions...
The SQL is the easy part and barely registers as an issue.
I see the same problem with SQL lovers rejecting ORMs as a dumb way to avoid using the right tool for the job.
But using an ORM is not about avoiding to write SQL. It's about all the rest: code introspection, data validation, documententation, having a common api, tooling, etc