Maybe Matt and his critics are both right
Matt makes a good point, just not one that's entirely clear, mostly because he lacks a language to specify what different "sized" programmers would be. Some folks bored everyone because they abstract things too much (too big). Others would drag everyone down in the weeds (too small). As one of my lead developers told me, "It's just as important to keep some people _out_ of the discussion." Heaven knows we have all seen this when some idiot manager gets invited to the team meeting, myself included.
Wilfred Brown and Elliott Jaques argued years ago that people have different sizes that match the size of work that they are able to do. This is not so much experience as it is one's ability to handle complexity in work. Think of when you say that someone "is working out of his/her league" or that someone "isn't big enough for the job". People who are same "sized" work well together. For managers to really work, they have to be the next size up or they don't add value.
I found that it was less a matter of personality and more a matter of this "size" thing. If you pair a Stratum 1 developer (in Brown & Jaques's speak) with a Stratum 2 developer, you are asking for trouble. However, if you pair a Stratum 2 with a Stratum 2, pair programming seems to increase performance.
Most corporate environments shed high developmental arc developers because they are a pain in the ass, so pair programming works well there. Many extremely fast-paced development houses have these same folks, and since everyone is about the same Stratum or in the same developmental arc, pair programming works well here, too.
So maybe Matt's point is right, as are his critics. It's just that we lack a language to nail down our discussion.