Feel free to ignore that article IF you know what you are doing. Joel has a lot of opinions, that usually sound really good, and only some of them have any validity.
For example the Netscape codebase that he complained about went on to become Mozilla, which was the base for Firefox, which has done pretty well. Furthermore there was actually no choice about rewriting the original - once Netscape pulled out the bits that were owned by other companies they didn't have running code. When the only code you've got clear rights to won't run, drastic measures are called for.
For another example, Perl 5 was a complete rewrite of Perl 4 from scratch. The result was a much more powerful, extensible, and simpler language. (Yes, Perl 4 was grammatically much more complex than Perl 5.) Perl 5 has been far more successful than Perl 4. (Some 15 years in the result is creaky, but there are still a lot of people using it.)
On the flip side I've encountered some true disasters caused by the refactoring mantra. When you start refactoring in place, it is like you're living in a construction zone. Worse yet, as you reconstruct it, your opinions on how to write it will change, and you're likely to change how you're refactoring it. After a few generations of this, you get a real mess.
That said, usually refactoring is a better idea than a rewrite. There are a lot of examples where complete rewrites have lead to major disasters. (If I'm feeling snarky I'd use Perl 6 as an example.) And businesses have real cause for concern about spending years rewriting a system, with the end result that they get back to where they started but with more bugs.
Furthermore be warned that the second attempt to write a piece of software is notoriously hard to do right. Look at http://c2.com/cgi/wiki?SecondSystemEffect for a description of some of the pitfalls. So be very, very cautious about starting such an effort.
All of that said, if the code is a big mess 2.5 years in, then you probably have something else going wrong. In my experience good software developers in a good environment don't generally wind up in that much trouble that fast. I'm not a big fan of assigning fault. But odds are good that neither developers nor management are blameless. And if you've got the same developers, and same management, it would be silly to predict a significantly different result.
Still if you want to start a rewrite, the first question is whether or not you have good unit tests. Because if you don't, then it will be much, much harder to be sure that your rewrite is doing the right thing. Furthermore I can virtually guarantee that the act of trying to write tests for the existing system will give lots of opportunities to find significant improvements.
If you've brought it up to the point that you have a good set of unit tests, and you still think that the rewrite is necessary, then you'll be in a much better position to pursue that. And if you still have pushback from management, well, it will be some time down the road from now, improving the code will have improved your skills, and hopefully the economy will be in good enough shape that a better job won't be that hard to find...