When you run up against this wall, it is often easier to write new software than to maintain the legacy code. Long term you are duplicating a ton of work at huge expense, but that is frequently the fate of successful projects: to be replaced with something sub-optimal that is nonetheless more tractable because there is less of it at the beginning and rapid feature development makes it easy to demonstrate value.
More often I've seen that all that fast development time is spent trying to replicate features of the old system that were missed or deferred when designing the new system. Strangely, when they have achieved feature parity, the new system often doesn't seem so easy to work with.
Loyalty gets you very little in today's climate. Why should I spend time understanding the current system that was developed on yesterdays hotness?
I need to spend my time here developing on the latest trends on a new solution (learning more from running into the same walls the current system did) - not learning the domain knowledge + old framework, so I can move on after a year and earn more at the next place.
Is this good for the world? No. But unless you want to swing the hammock and work at institions that value incumbents, the incentive is to do whatever work improves your resume, not what benefits the company.
I don't personally like it, and I often see old systems that are just fine get thrown out and replaced with the a less featured replacement that grow into the same kludge as the first, but I can't ignore that when you do that you learn way more and have better examples to point at in interviews.
