Everytime I read articles like the one above, I'm put in mind of the phrases "baby" and "bathwater", and "throwing out the, with..." Just because you can cite one or even some successful software projects that fail the "Joel Test" doesn't mean it's not valid. Just because Linux succeeded in-spite of Linus' attitudes towards specs and source control doesn't mean that they are not good practices.
As far as XP Programming, I don't think it succeeds in spite of the "Joel Test", I think that some of it's tenants just hit "edge cases". For example, "Programmers work and communicate in pairs, so working conditions aren’t supposed to be quiet." Now, I don't work with XP, so I can't say for sure, but from everything I've seen, the pair is still going to need to work in relative quiet. You now have two programmers concentrating on the same problem or set of problems. Between the two of them, they can bounce ideas off each other and still maintain their concentration, because "that's how they are supposed to work". But add in a third vector, like a phone, and it'll all come crashing down.
(I tend explain programming like juggling, probably because of Joel's original article.You have all your balls up in the air, and can handle them, can handle new balls or bowling pins, or chainsaws, and can change object, picking new ones up, and put some down, but ... somebody tosses a new object into the mix, and you're probably going to drop them all. Extend that to pair programming, just put two people doing the juggling. You can have more balls in the air, and more complex patterns, but an influence outside of the jugglers is still going to mess things up.)
Besides which, arguments like Wesner's really only take into account the letter of the law, not the spirit of the law. A "quiet working environment" doesn't mean one programmer per office, it means a working environment conducive to your methodology. "Best tools money can buy" doesn't mean upgrade the minute faster hardware comes out, it means make sure that your start with a good solid baseline that allows developers to be productive, and go from there.(I have 3 monitors. I like having 3 monitors. I'd get a fourth if I could hang one from the ceiling, I think, but.. does everyone need three or four. No, but two is a phenomenal increase in productivity. And far more cost effective than a 1 larger monitor. Same thing with VS 2005. It's a great tool. Shops using VS 2003 should move towards it. Don't have to do it this year, but it should be a goal. When it's appropriate.)
I'm sure that some successful projects would score low on it. And I'm sure they can continue to be successful.But I bet they'd be every more successful if they applied more of these practices.