The problem always lies on excessive abstractions and patterns on the backend side. Which really isn't solved anywhere by any strategy other than keeping things damn simple.
Your descriptions of "impedance mismatch when converting relational models to business models" and "automating mappers that leads to a hardened and immovable design" are a precise example of that: OOP patterns muddying the development process and causing problems in unrelated parts of the system (in this case the database).
Of course, keeping things simple and programming in a way that fits the relational model is incredibly difficult for developers that have been trained to believe that complexity is the answer to all problems future and past. So the resort for those people is to keep pestering management to throw the baby (relational databases) with the bathwater (relational mappers and other related OOP patterns).
And when people needed the transactional data in a relational model, we streamed events and that was read only in some other tool and the core system didn't need to know about any of that.
Been down this road. Saw a fork in 2015 and haven't looked back.
It sounds like you put ORM hell behind you by getting rid more of objects than of databases.
> Not only were we able to build faster (schemaless is so much easier on change management), but also offers the ability to add features at a frighteningly fast pace
What kind of change management? Frightening clients with API changes? Eluding code reviews and formal release processes?
I've seen this way too many times to back off of my assessment. Relational models do not, in the long term, enable an agile business model. It is an anti-pattern even if it takes years to reveal itself as such.