To utilize all those benefits you can't rewrite everything at once from scratch. You need to do it incrementally.
On incremental improvements you should be able to stop what you are doing within a week or two and be ok with leaving the code like that for a long time.
Incremental improvements require more skill. The sorts of skills that make you a better developer. So even though it’s more difficult, it’s much more valuable to all parties for you to attempt it.
The only reason for a rewrite is when you have a language or framework that’s dead, and there are often other dynamics that put you in that spot in the first place.
There are a bunch of common mistakes people make with trees that take years off their life expectancy. The worst guarantee the tree will be dead in twenty years (and potentially dangerous before that). Software has similar phenomenon, on a much shorter time scale.
My knee jerk reaction to rewrites is so negative I actually would like some counter evidence on when it worked out.
[1]https://www.postgresql.org/message-id/4658520e-5cd0-6242-e54...
The common factor is doing it gradually, basically page by page. There is no big switchover, new code goes live as it is ready. We have some very competent people with long tenures which surely helps.
I'm not against rewrites, sometimes the company grew so much that you need to start from scratch and rethink given your current knowledge. Or you started with a low fidelity prototype and you rewrite to create a production ready feature, without the crufts in the design you had when you started.
Edit: refactoring is usually considered to be done on existing code base. I really mean thowing a whole component away and re-doing it from scratch. The components need to be small enough though, that you can deliver them to production within 2-5 months.