Completely agreed, but this is probably the only real use for this technique. For experienced (read: expensive) developers, the cost overhead of having two or three developers working on one problem (which is likely a one-person task anyway) is too great. I'm certain proponents would push the quality angle -- that two or three pairs of eyes and brains focused on the problem improves quality -- but there are other ways to boost quality while maintaining a more realistic productivity and cost structure.

For less-experienced developers though, this would be a great way of building team cohesiveness, training/mentoring, plus likely boosting productivity.