A clean rewrite is almost always going to produce better code than what already exists in a project that has grown organically.

The current project has had numerous iterations on requirements over the years, changes in project leadership, paradigm fads come and go, and all that time accumulating cruft and layers. Looking at it at a single moment in time, you have a fixed set of current requirements where all the discovery has already been done, plus whatever your current knowledge of future requirements is, possibly none of which may have existed when the original code was written.

That doesn't mean that everyone is going to sit around on their thumbs patiently waiting for you to rewrite it to be perfect. The more lines of code there are, the more time it will take, and the more hidden features that nobody really remembers exist but are still crucial will crop up.

Few situations are actually best served by a full rewrite, but almost every project would be better off if the world could stand still long enough for it to happen.

Ideally, you want people deeply familiar with the original codebase doing the rewrite.

What usually happens instead is that the rewrite happens because the original code has been handed off to a new set of people. They're not deeply familiar with the code. It's confusing to them. It's not obvious why things have been done in a specific way. And so they decide rewriting it from scratch is the better option.

Unfortunately, they're not in the best position to come up with a solution that incorporates the right lessons from the original design.

a rewrite from scratch is a pipe dream for almost everything bigger than "hello world".

just ask WordPerfect.

any kind of home grown business app will have corner cases and requirements spaghetti that would take much more time to figure out than to write actual code.

and if the person asking you to do a rewrite just shrugs when you ask "where is the test suite?" walk away asap.