>The difference here is that the existing codebase isn't just broken, it's structurally resistant to being fixed.
The key point here then is that the engineers and maintainers of that original (legacy) system probably did not properly take scalability and structure into consideration. Maybe the system was pre-SDLC, which is an important consideration, but each system is usually a different case, and some tech is often labeled as "legacy" because it's simply not part of a "bright and shiny new money-making solution" marketing plan... ehem.
It's important to not create the same issues in redevelopment, and reducing complexity is a key step in ensuring future compatibility.
Some systems are not as "legacy" as others. This is also a vital point to the discussion.
Most clients aren't concerned with overall cost and lifetime of service on solutions from what I've observed; Most clients are people working towards raises and their retirement and just concerned about not exceeding their max budget and not generating embarrassment for themselves or for their company.
This is why one of the first questions I ask of my customers is how long they intend for the system to be in service for.
There are several factors of why a proper solutions architect is necessary throughout the development process of major and mission-critical systems, but too many PMs decide to just use the tech stack a team agrees upon, or what's cobbled together and patched to work, or what worked as an MVP during early demos.
We suffer from environmental factors, because budgets are under-cut, deadlines are always too short, and because people only care enough to prevent their own headaches. This does not meet a mark for vital systems though. As we ignorantly rush towards more and more software dependent operations, the failures will become more and more amplified in all aspects (cost, loss, recoverability, technical debt... you name it).
Keeping everything as simple as possible is now, and always has been, the better ideal.