Thanks for all the feedback, it's definitely food for thought.
I'm in agreement that pair programming can be highly beneficial for knowledge sharing, continuous code reviews, that sort of thing; with the caveat that the pairs are actually suited to constant pair programming (not all programmers are; but that doesn't make them bad programmers).
But pair programming appears to have a law of diminishing returns if it's done ALL the time (not counting XP spikes which tend to be solo-coded anyway, of course). The alternative to constant pair programming doesn't have to be (and really shouldn't be) "constant solo programming". Some hands-on team leading, regular design discussions around the whiteboard, occasional pair programming, shared (and continually updated) domain model, project wiki, mentoring junior coders etc, can work wonders for knowledge sharing and code quality, without the added overhead of two programmers working on one program (I know I'll regret mentioning that!).
(Quick note on mentoring junior coders: not ALL the time, obviously. At some point they'll benefit from cutting the apron strings, heading out into the scary world of solo coding, thinking for themselves, learning without a "security blanket" there to tell them it's okay. Mentoring==good, mollycoddling==bad).
Naturally, if you work in a pair programming team and you enjoy it, best of luck to you: don't change what isn't broken. It just isn't for everyone or for every situation.