I once worked at a place that had pair programming as a rule as well. Fix button size CSS for IE6? Two programmers, one computer. Change First Name, Last Name to First Name Last Name? Two programmers, one computer. Being stuck on something totally trivial yet essential where you depend on someone else? Two people sitting on their hands instead of one.
So this is what it ended up being: one guy doing the work or sending HipChat messages to the guy required to get unstuck while the other one was browsing Facebook. Then in the end the guy that was picking his nose all the time looks at the other guy's work quickly and you say "yeah....that seems about right....merge it!".
Sure I can imagine it's great to work out the architecture of your new framework together with a few guys and a whiteboard and then starting to work on the code together. But why would somebody need to watch how you're doing some kind of trivial CRUD?
Unless literally every problem and feature they're doing is super exciting sooner or later somebody is just colouring between the lines to get the application finished and a quick code review when it's time to merge the pull request is all you need.
I am an advocate of paired programming. A lot of organizations do it really poorly. Your examples show exactly where it does not work.
First off, sometimes you have a bunch of minor tasks that need to be taken care of, like updating some text in the UI or fixing a button size, also in the UI. Is there a reason that you have to sit down and plan to only do that? If you have a well prioritized backlog and the freedom to get work done these scenario's should be more like:
"Let's work on adding this new feature here." "Ok that's a good one, we'll need to do a, b, and c to get it all wired up, working and tested. Hey since we're in that part of the code there are some small tasks about changing the button size and the text here, let's make sure to get those done." ... "Great! we completed the new feature, fixed the button size, and the text. Merge it!"
I never sat down with my pair for the day and said "Ok go fix that button. Great, merge that. What's next?" It was always a discussion of the most valuable thing to get done and any collateral issues that could also be fixed. In this case, we often got more done.
Second, if you had a pair partner sitting around doing nothing, there is a problem. They aren't engaged. They either need to become engaged or not be in an environment where there is paired programming. That is ok! But they need to admit it and move on.
Pairing works well if you have the people and processes in place to allow it to work well. If there are people sitting on their hands, then there is a problem. Though I would argue that if you took away paired programming, the same engineers would often still be sitting on their hands, playing on facebook.
We had a similar experience at my last company, and we tried a few ways to get around it, eventually landing on a workable solution.
We started to allow devs to do story cards on their own, for easy stuff (like you said - colors, alignment fixes, CRUD, etc.)
This worked for a while, but we found the number of dev/bug/fix/bug/etc cycles on those stories was waaaay higher than cards done "properly" with pair programming (even big architecture cards).
So then we made the rule that a dev could do a card on their own, but just before committing they would sit down with another dev and show and explain it to them, thus helping to catch any little "gotchas".
This works really well. i.e. the whole point of Agile is there are no rules, you're supposed to come up with your own based on what works best for you and your org.
So this is what it ended up being: one guy doing the work or sending HipChat messages to the guy required to get unstuck while the other one was browsing Facebook. Then in the end the guy that was picking his nose all the time looks at the other guy's work quickly and you say "yeah....that seems about right....merge it!".
Sure I can imagine it's great to work out the architecture of your new framework together with a few guys and a whiteboard and then starting to work on the code together. But why would somebody need to watch how you're doing some kind of trivial CRUD?
Unless literally every problem and feature they're doing is super exciting sooner or later somebody is just colouring between the lines to get the application finished and a quick code review when it's time to merge the pull request is all you need.