>Because requirements weren't properly clarified before work began

Yea, software is typically way more flexible and fast moving in the real world.

At start of project: "We need software with A, B, and C"

In middle of project: "Our competitor has released with ABCD and E, and if we don't add at least E we might as well cancel the project"

There is also - Our software works 100% fine with what we expected in the field, problem is (new|old) thing showed up and now we have to work around all the bugs in it.

Then there is Chesterton's fence. That 'broken old crap' was actually doing something highly specific that calcified into how the customers systems work. People love ripping crap up and changing stuff, until they figure out it just broke their enterprise clients workflow, and that client pays their salary.