Any change to a badly written application can break some obscure functionality or integration. I repeat, any change. Assuming that you're still working on the codebase in question (and why else someone would care to rewrite it?) there is a constant threat of breaking changes. Heck, with certain types of code regular issues after updates are nearly inevitable.

If you rewrite something, you will at least have understanding of how things work right now, which allows you to quickly and reliably deal with surfacing compatibility issues. On the other hand, updating legacy code to deal with those issue is a) much slower b) likely to introduce other issues.

And no, you cannot always slowly refactor old code. That is, in many cases it will take several orders of magnitude more time that a complete rewrite with new features plus all the rewrite issue mitigation.

Been there, seen that. Many times. So far I haven't regretted a single rewrite I've done in my professional life. If your experience is different, than maybe, just maybe, you should look at how you approach rewrites, rather than dismissing the whole concept as "wrong".