It depends on how you measure productivity. If it's measured in LOC/hour or something, then pair programming will definitely seem like a huge productivity hit.
If you measure productivity more like "features delivered per month" (and negatively adjust for bugs that make it to production) I contend that pair programming will probably yield more favorable numbers.
If you've got a high fault rate, two people working things out might improve things enough to be worth the while. Especially in a case were uncaught bugs are really band and/or your daily coding is an exercise in tedious input checking, c.f. some web sites and conventional GUIs.
And even then I'd say that the occasional meeting plus a decent code review process would probably be as effective, without the hit in performance. Never mind the sheer annoyance a lot of people would feel having to "couple" all the time.
There's no credible evidence to support that claim.
On the other hand, pair programming generates a lot of churn (discussions about details between the pair programmers, the outcome of which bears little consequence on the solution of the problem) and that alone is guaranteed to negate whatever gain you could expect from pair programming.
In my experience, asynchronous code reviews work a lot better.
My experience supports it. Can you point to credible evidence to support your claim?
Like I said, some people might be wired differently. Although in this case, it's hard to imagine getting a > 200% productivity increase out of two people to make it worth it in the long run.
For short code golfing sessions, sure. That's been called "could you help me with this code?" for a long time, before that nice alliteration was invented.