They do, but that doesn't mean the decision is wise. The point is you are creating more bugs than you could ever possible fix in this kind of refactor.
And those bugs get fixed, and the software ends up better.
I've contributed to two successful "rewrite it in Rust" projects now: Stylo and WebRender. Both of them ended up fixing long-standing bugs in the previous implementation that were difficult to address in the old codebase, but a new clean approach offered a nice opportunity to fix them.
I also err on the side of never re-writing things, and pros and cons must always be weighed on a case by case basis. It's not possible to say in general that re-writing software in a language not prone to many important classes of bugs would "create more bugs than you could ever possibly fix." We won't know the decision is wise or unwise until it's attempted and studied maybe even a few times over.
If you're rewriting into a language like C++, this may very well be true. However rewriting in Rust in my experience yields far fewer bugs, and the ones that do surface are usually simple to fix. If a project truly is "stable" - there's very little effort involved in maintaining it, then yeah, it doesn't make sense to rewrite it. But if it's plagued by bugs and is painful to maintain, you'd be much better off rewriting it in Rust, assuming you're familiar with the existing project's limitations.
