Most of what's going on in the Agile and XP community is the "emperors new clothes" because the reality is that business constraints sometimes prevent you from entirely adopting a methodology or a practice. In addition, many times you have to be creative in order to get your team to be productive and figure out which of these practices work for your environment and which don't. But laziness usually prevails, and people get comfortable with blindly adopting these recipes.
I believe engineers (and some of the advocates of these practices) refuse to understand that not everyone works for a startup, not everyone works for a bank, not everyone works with an outsourced shop, not everyone works for IBM, etc. More importantly, not everyone is the same and some people are more productive *in* their comfort zone, not *outside* of it.
I'll personally try everything once, but not if I'm forced to. And, in my humble opinion, that is important to keep in mind - whatever practice you think of, forcing it on your team is not democratic. People who are uncomfortable with doing their job will either leave or become unproductive.
Strictly on the pair programming issue, I rarely use it and when I do is only for training purposes and getting people up to speed. The problems I've met in delivering projects never had anything to do with not using pair programming :)
But, again, this is *my* experience and *my* opinion :)