I'm a fan of pair programming. I owe a lot of this practice to my improvement early on in my career. I define pair programming as two developers working on a task using one or more machines at the same time.
I have had some excellent pair programming sessions. I can even remember some of them in great detail. Here I went away learning something new, solved a difficult problem, or just generally had a fun time.
On the other hand I've also had some awful experiences, which unfortunately I can still remember. Here my partner wouldn't play the role of the driver or navigator correctly, wouldn't be engaged, or just generally didn't get into the flow of pair programming.
Team's mandating 100% pair programming is bad. Some tasks don't need two developers to be working on them concurrently. Here pairing should be used.
Pairing is two developers working together to solve a task, but doing so separately. During pairing regularly communication, design sessions and feedback should be used. You can even join up to pair program on complex areas. The difference is that unlike pair programming you don't need to have two developers working on the same part of a task at all times. Pair programming and pairing are two very distinct concepts.
The key takeaway here is to know when to use pairing over pair programming and vice versa. Both have their merits and should be applied in the correct context.