First, don't place isolated works of genius against the mundane day-to-day work that most people do. Most of us aren't geniuses. I'm not an Einstein, and I'll never look good compared to him.
Next, I don't think it's that vociferous a demand in the industry. Most of the industry still resists pairing, regardless of results. And certainly, nobody is saying that it's impossible to be productive unless you pair.
Now, some positives for pairing. First, it's a risk management approach. Businesses generally aren't interested in maximizing productivity. They're interested in minimizing risk. Don't believe when they say otherwise, they're full of crap. (To be precise, they're interested in minimizing the APPEARANCE of risk more so than risk itself, but.) Depending too much on the results of individual programmers who could quit, be incompetent, or get hit by a bus is a business risk. By pairing, the knowledge gets distributed throughout the team. Moreover, it helps mentor junior programmers and integrate new staff.
Beyond that, I just find it a useful technique in many situations. Programming requires thinking on several levels at once. I've found it very effective for the driver to focus on the individual lines of code, while the kibbitzer keeps track of the big picture. It also helps keep you going when you hit a roadblock, rather than checking Twitter and coming back to life two hours later. So there are real productivity gains to be had.
Have you ever seriously TRIED pairing?
No amount of productivity metrics can overcome this drawback. I'm not particularly introverted, but the same moment someone tries to force me to do pair programming for longer that few minutes a day at the time convenient to me, I would start looking for another job. What's next? Trying to feed me with energy drinks to make me more durable/productive? Or giving me drugs to make me more creative/productive? Thanks, but no thanks.
But again, it's not about the productivity of the individual. It's about the productivity of the organization. If I put on a manager hat and one programmer can't deal with team processes, no matter how good she is, she's gone. If I want the benefits of pairing for a team, I won't hire programmers or keep programmers who can't deal with it.
