There are lots of different types of rewrites, and rarely does anyone find themselves in the position to rewrite an existing system in a way that perfectly reproduces behavior 1:1, because rewrites are often motivated by a ton of ugly features/flows that were forced as kludges, where the whole point is to improve them, along with making it vastly easier/cheaper to write new features.
And no, waterfall works just as badly for rewrites as everything else, because when it comes time to program it, you run into bugs and unexpected behavior with libraries and the realization that your new architecture has problems and all of the problems that come with regular non-rewrite programming.
That idea that "First you need to determine the requirements. All of them. In excruciating detail." is the problem waterfall always encounters -- to write the perfect list of all requirements, that's ultimately writing all the code. Such supposedly perfect waterfall specifications are an illusion.
So no. Approach rewrites with the modern common sense of any software project, which involves defining and building out working components incrementally with testing, according to defined high-level priorities, and flexibly dealing with issues along the way as you run into the same unpredictable problems you always do.
And finally:
> Leaders who have delivered successful rewrites often describe the process as one of the greatest accomplishments in their career, but they never describe it as fun.
This sounds made-up. What leaders? Why would a leader ever describe a rewrite as one of the greatest accomplishments of their career? I've never heard of such a thing. And why shouldn't it be fun? Rewriting something to wipe away all the old horrible tech debt and start over from scratch can be super-fun!