Not the person you originally asked, but I have the same rewriting habit.
Automated tests are essential for rewriting code. If I want to rewrite untested code I either add tests or don't rewrite it. The rewritten code also needs to be tested.
Whenever possible, split up big, untestable rewrites into a series of smaller, testable rewrites. Let's say I want to rewrite component A with subcomponents B and C to use some new library Foo. I might first rewrite B to use Foo, then rewrite A (and A's tests!) to work with rewritten B. Then I rewrite C to use Foo, then rewrite A again to work with rewritten C. Then I finally go rewrite A to use Foo. This is more coding then doing the whole thing in one go (I rewrote A 3 times!), but it's a net time saver because when I make a mistake I can quickly find and fix it.
When I'm on the clock I rewrite code for practical reasons (maybe the current structure of the code can't support some new requirement, or technical debt has gotten high enough to make maintenance difficult, or whatever). This is rare-ish. Rewriting code, especially production code, is risky and time consuming and just generally not worth it.
Most of the time when I rewrite code I'm rewriting my own code, and I'm doing it for personal reasons. I like good code, I like reading it and I like writing it. To me code has aesthetic qualities, code can be beautiful and elegant. It's also educational. Imagine a writer that never edits their work; they're probably not a very good writer. It's also fun! I'm already familiar with the problem domain, so I can devote my entire focus to solving the problem instead of splitting my attention between solving the problem and figuring out wtf is going on.
