Pair programming is good for UI/HCIish code and so so for other types of code. Studies have shown that human are not good at multitasking even though it makes them feel productive.
Personally I think pair programming is overrated while code review is still underrated.
Most web designers don't grok <your_favorite_langauages>, but some limited template languages/tags. A web framework without template doesn't scale in terms of development resource unless you figure out a way to automatically translate a template delivered by a designer to your Smalltalk code.
Short summary: he thinks that every line of code is design because the final code is the precise spec.
This is an interesting but narrow POV. What if you "design" an algorithm in Haskell and what to "translate" to another language? Calling the "translation" process design would be a bit of stretch. Implementation seems to be an appropriate word here.
Retrieving data to process and storing back to some giant "storage units" are becoming more and more obsolete. The future is google style: data is replicated and backed up at all times and you push computation to data to explore data locality.
Then your point is moot. The context is startup. Eric does a good job for a post-startup, which is already very profitable with a revenue of $86m in 2001 (http://investor.google.com/fin_data2003.html). As a matter of fact, many think that Eric is more "lucky" than "good", given his track record at Novell.
Personally I think pair programming is overrated while code review is still underrated.