I can answer from experience. The reason is that generally people can find success by doing one or two things at a time, and then polish them through testing an

I can answer from experience. The reason is that generally people can find success by doing one or two things at a time, and then polish them through testing and bug reports. This often means that the wrong things are done for the right reasons, and the debt gets bigger and the value of the system increases. This makes big rewrites really hard. This locks in the complexity, and inertia makes change expensive. I experienced this when I built a tcp socket over a request response library, and the reason was to capture the investments made in the library and suffer the pain of building tcp. This made the code complex, but it was reasonable to sell to stakeholders and achieve success on. Now, I wanted to just use a socket, but this took 1.5 years to do by slowly iterating on the right value proposition. I'm a big fan of slow massive rewrites, but it requires consistent and solid leadership to pull off.