You don't think this depends at all on the particulars of the developer(s)? E.g. their personalities, experience, skill level?
So yes, you're correct.
It's the 100% pairing, or worse, 100% mob programming (up to six people with one screen!) that I can't believe would ever be more efficient than the programmers working independently.
Sure, have a party and mob-program for fun for an afternoon, or solve a particularly sticky problem that way, or use it to transfer knowledge about the system to the wider team. Have a blast, and teach everyone something useful at the same time. By all means.
Just don't pretend (as pairing/mobbing advocates do; not you) that two people sitting at a computer can be as efficient at day-to-day coding as two people coding separately, unless at least one of the two is a junior or near-incompetent developer who would contribute negative productivity on their own.
But you are right that voluntary pair programming can be a good thing, so we shouldn't ban programmers from pairing if they want to. But the discussion is whether it makes sense to force programmers to pair program. I really doubt that for example pairing John Carmack and Linus Torvalds would be productive, and that is the kind of personal pairings you get at work.
I absolutely can pair for such an event. I'll pair for knowledge transfer. I'll pair for fun. If every second counts, or if the goal isn't maximum productivity throughput, the sure, pair away.
My point is not that it can't help for world-class developers, but rather that two world-class developers working on routine coding are absolutely not more efficient than two world-class developers working separately.
And people who advocate for pairing typically advocate for 100% pairing. Which can be fun but it won't be more than 2x as productive as two world-class developers working independently.
How? "Deploy personal + company resources as appropriate to get the job done together" - however they damn well want to in that framework. It is between them. The pair could:
Use a whiteboard for 5 minutes every 3 hours and go their separate ways otherwise.
Sit together hunched over a single laptop.
Work from two entirely separate locations with collaboration software so they can see each others cursor and typing as they voicechat.
I mean, isn't it all about simply getting along and getting a job done?
Hard problems are quite rare, most development is mundane.
When facing hard problems, generally related to non-obvious bugs, there are many ways to solve them, and yes taking time off to think about it separately is absolutely one of them.
This isn