Substantive-not-incremental change has always been possible, but it's mostly avoided for being a bad idea. Only when we identify an opportunity to make substantive improvement, clear and well understood, should it be used; the default is substantive destruction which is rarely more helpful than harmful.
In software terms, they're looking to rip out entire modules, because they don't understand the business logic that demands those modules. Such substantive change would be pretty idiotic in almost all cases. Refactoring is virtually always the better choice, even if it's hard and takes a long time.
Ripping out a module entirely, only to find it was necessary after all, tends to lead to the same module being rebuilt piecemeal as the missing logic is identified and being as bad or worse than before. In the end, you still need to refactor it if you want it to be good. If you can't afford to refactor, (and you don't have well understood problems,) you're better off not changing anything.