This reminds me of Joel Spolsky's Things You Should Never Do (http://www.joelonsoftware.com/articles/fog0000000069.html). It's old advice, but still as relevant as ever.
The world is full of tons and tons of successful, large-scale software systems (from apps to languages to databases to OSs) that were not only "rewrites" of older systems, but had to be written because the original system had incurred too much technical debt.
So what Joel really meant, deep down inside, was "okay it's not that you should never replace large systems from scratch; it's just that you should be very circumspect about it, OK? You don't just go knee-jerkedly ripping out the old stuff just because it's a ugly, a pain to deal with, unsexy, etc. You have to look at the whole picture, and understand the (true) business costs of what you're doing. That's all I'm saying."
What I took away from the article is this: whenever you're thinking of rewriting from scratch, there's a better way - incrementally replacing the code. It's not as fun, and it feels worse, but it ends up with much better code. I'm pretty sure this is nearly always true.
Joel outlines the reasons, but the most important one, imo, is this: you're not going to do a better job. You think you are, because you see that the code is a mess and think you're better than the people who designed it. And you're probably right (or at least, you know more.) But a system that has years of work on it is not something you can whip up again from scratch - you're going to miss all the same things they missed the first time, when they were designing it, and either recreate all the bugs, or make your new system a mess.
Incremental improving is nearly always the saner solution.