Engineers always under estimate the amount of business logic in an existing application. This is one reason my mainframe apps are so hard to replace, they often have 30 years of business logic built into them.
I agree with you on principle, but I've always wanted to see one of these "30 years of business logic" apps up close. What's most of that business logic? I can't imagine all of it being essential and at the minimum possible complexity.
"Normally, component A completes then sends a message to B, who blocks while a file operation occurs, and then sends a confirmation to C which updates the UI. When configuration option D is enabled, B must make the write twice because of X, which requires component E to act as a delegate to intercept the normal message from B to C so that this can occur without changing the implementation of C, since it has been externalised and is used in six other projects. Also, file writes are disabled on weekends, except the fourth weekend in February, unless this weekend doesn't occur."
-- snippet from a more or less realistic set of requirements for a "2 years of business logic" app. I do not want to be here in another 28 years...