Actually, the more experience I get, the more I think Joel was wrong. Like anything in software, I've had the experience that there are good ways and bad ways to do rewrites. Start with the reasoning for doing it:

Bad reasons: "The code is messy", "It's written in language foo while all the cool kids are using language bar these days", "It's slow".

Good reasons: "The architecture is too tightly coupled now and it won't scale without untangling major pieces anyway", "The lack of our forward velocity is directly related to problem XYZ in the code, and here is how a new architecture would fix that."

In other words, I feel like I can sniff out bad rewrites now, which are generally lack a sense of focus and a true, enumerated list of problems with the current code base. Good rewrites have clearly delineated benefits that the rewrite will bring, stuff that brings measurable value, and show that the rewrite will bring things better and more cheaply than what's possible with the current codebase.