It's not the rewrite that's the problem. That's fine when warranted, and often is as codebases go through decades of writhing around with different technologies, figuring out user requirements ad hoc. Many companies have pulled off the rewrite successfully and for the better. Windows is a very good example. NT was a ground up rewrite. It took about 10 years, but Microsoft successfully moved the world's largest installed base of software over to a complete rewrite. Anyone want to argue that getting off DOS wasn't worth it?
How'd they do it? Good technical management, good product management. Overall, just "good management" of the process.
So why does Spolsky call out the rewrite as being something you should never do? The answer is one of visibility.
A startup with poor management--or even a new product at a large company--does not have the same visibility as the rewrite of an already successful product. A poorly managed rewrite of a successful product has visibility towards success and failure... mostly failure. If the rewrite is successful, no one talks much about it (when's the last time anyone brought up migrating Windows from DOS to NT? 2001?).
This is how people like Spolsky can make statements like "never rewrite" and people believe them. Empirically, it seems like rewrites are prone to failure because we see them.
The problem is, it's not a matter of causation.... rewrites do not evoke failure, or even make failure more likely. It just so happens that those are the most notable failures, and seem to make Spolsky's case (Digg is a recent example that brought this topic up again). Meanwhile, many startups with poor management and poor technical choices are currently sinking, unnoticed, as I write this.