I have similar thoughts to Joel Spolsky, but in a domain outside of internet browsers.
At a former company we attempted that epic rewrite. It did pretty much everything wrong you could think of, from over-hyping the rewrite to the customers to the attitude behind it. For 3 years we labored hard with no product, only an embarrassing prototype, until we abandoned it and came back to the old one. The damage to the company's reputation was never fully recovered, as well as its morale.
Yet one of the things that bothered me personally, even when we decided to do it, was that the team echoed a similar attitude you did. When asked about the product, all they could talk about were the negatives. And they were justified, the codebase was a stinky mess. We actually had C functions that were 20,000 lines of code with hundreds of variables declared at the top, and that wasn't some one exceptional case in the system, that was the norm (our product had a 3-decade legacy). But they had little good to say about the actual product, its workflows, its designs, which tens of thousands of users worldwide loved and used.
A Remake Requires Love
Imagine taking a classic, beloved film and having a film director who has nothing good to say about it be in charge for remaking it. Is that going to have a reasonable chance of success? Almost certainly not, and yet teams compelled to do rewrites often approach it with this kind of attitude. To remake anything requires love for the original, not hate.
A rewrite doesn't just boil down to time, and the time will always be longer than expected. There is design continuity here. If you have this legacy product and there was a compelling enough reason for a company to continue paying the staff to work on it, it probably has a reasonable customer base of people who love it, depend on it for their livelihood, etc. They don't see the stinky codebase.
Now, take a team who absolutely hates that codebase. In a worst-case scenario, this would be an even different team from the original team that designed the legacy product. This exposes us to a very high risk of creating something which customers like even less than the original. This is especially true if the team is blinded so much by the product's technical flaws that it can no longer see what it did right.
So I really recommend refactoring, at least trying very earnestly here as a first step. Don't even consider a rewrite until a genuine attempt is made unless there's some reason that forces a rewrite (ex: a change to a new programming language and hardware/operating system that doesn't allow the former one to be used).
But moreover, refactoring or rewrite, there needs to be an appreciation for the good user-end aspects of the original product. There needs to be an appreciation and faith for the decisions of the original product that turned out to be a hit with its user base. Until that is appreciated, no substantial change or rewrite of the original product can have a good hope of achieving the success of the original.
It takes a much longer time to go from a fresh product with potential to a mature, tried and tested product. The latter can take 10 years, the former might be doable in a year.
Another thing to keep in mind is that appeasing existing customers for a rewrite is typically a significantly higher priority than gaining new ones. If the desire is to reach a whole new customer base, then it would be a new product rather than a rewrite. It shouldn't even live in the shadow of the original. But if it's a rewrite we're talking about, existing customers are the most important.
Anyway, those are my two cents, and they're very much aligned with Joel from having had a not-too-dissimilar experience.