One theory of pair programming is that it keeps developers honest. That doesn't seem to be as true as I thought. I've watched a programmer get his tests passing, claim he was finished and then had his pair sit silently, despite the fact that the follow-up refactor was not done, the code needed some serious cleanup and the tests were woefully inadequate. Programmers do not always have the best social skills and many find it difficult to tell someone else that they're not finished or they say it so bluntly that feelings are hurt. Pairing is inherently a social activity. With geeks. What could possibly go wrong? We can sit around and discuss, ad naseum, the intricate details of various Linux distributions, but pairing doesn't just require compensation for different technical skill sets, it also requires compensation for different motivation levels and that requires people skills that some of us simply do not have. This, I think, is an inherent contradiction in the needs of pairing versus the abilities of people actually engaging in it.
We've had programmers fall asleep because they were so bored while pairing. Another programmer was caught playing a Gameboy while pairing. And let's be honest: there are some programmers that no one ever wants to pair with. One programmer, no longer with the company, summed it up quite nicely when he said "Pair programming is great. If I show up with a hangover I can just grab a pair and let him do the work."
Pair programming is a great idea but it is not a cure-all -- of course, no knowledgeable XP proponent claims this. The team I work on has six programmers. Recently, we had a programmer get promoted while we were still one person down. We had, in effect, four people to do a six person job. Hollywood really doesn't care if we're short-staffed, so pair programming got tossed out the window and everyone kept working like mad to get things done. And we did.
Several months ago when we stopped pairing due to workload, our bug rate went up, but this time it hasn't. Instead, our productivity went up significantly and management is, predictably, very happy about this. We've not abandoned pairing. The rule of thumb we use is "grab a pair when you need it." We're having some issues in that we still need to spread knowledge around a bit more, but so far things have worked out very well. I'm very curious to see how our deformed XP variant will perform in the future.