What usually happens now is researching and understanding the business domain is rushed, flawed assumptions are then mapped to a flaky, misaligned database model/prototype and then a mountain of code is furiously piled on top of that.

When you finally understand the domain, it's too late. Because you rushed to deliver "something".

Nobody dares to rework the DB model as it's too risky and expensive.

So you remedy it with transformer layers, refactorings, abstractions, advanced types, tools and tests.

You treat the symptoms.

Teams that aligned their DB model with their business domain early on have it easier in every possible way. Performance, correctness, stability, velocity.

Also, I can't remember the last time I saw data modeling mentioned in a job post. And I've seen thousands of them. From SWE to CTO roles.

My guess: business analysts, data modeling, diagrams, long research cycles sounded too waterfall-y so it had to be killed by agile.

I will say this about agile - we didn't get this right the first time. If we didn't plan for a little bit of failure and iteration, we wouldn't have found this solution.