Well, OK. I've heard some teams can pull this off. I've never been in one, though. The problem I had when I tried (beyond the tension from lack of personal space) is, you really have to coordinate a lot of cognitive functions together. I found pair programming easy when it's just one person typing out something trivial, and another checking for typos. But it gets exponentially more difficult if the task is non-trivial, requiring some thinking and exploration up front. You now have both programmers cycling through ideas in their head, with the stress of each idea being subject to immediate evaluation by a co-worker.
The way I see it, successful pair programming requires the kind of brain tuning they did in Pacific Rim - the people involved must be "drift compatible", or else it doesn't work.
It is the whole stand up routine again, with who types what, how much time the keyboard is given to each one, ....
But as you put it, any non-trivial task, e.g. where you're creating multiple new classes and refactoring along the way is hard to do with pair programming.
Pair programming in its many forms is great and all, but not everyone can do it and neither can it be applied to every problem.
So again: FORCING people to pair is a bad idea.
If it’s about bigger packages like user stories I agree that usually multiple people should work on it in parallel. Not necessarily together.