That probably wouldn't work for me. I learn better by reading (good documentation; failing that, code) than by listening. Conversation can be erroneous, but code (even bad code) never lies. I think optimal learning methods differ from person to person.
But code isn't setting you up, human-written documentation (or, in the case of the article, humans) are.
He gives an extended example where pair programming enabled a new hire to configure his work environment in a half day (plus Misko's half day). I have found that a well documented setup procedure enables a new hire to set up his environment in half a day without involving a senior programmer. The second example of walking the new programmer through his first bug fix seems quite reasonable, but that is not pair programming in the large.
The comments seemed to be divided into two groups: those who were doing pair programming and loved it and those who were skeptical but were not pair programming. I admit I am in the second group. I would be interested in the experience of HNers.