Sorry, last time I looked for references I couldn't find them. But I did read of at least one study to that effect. To me it seems like proving the sky was blue, though.
Remember, to be efficient, pair programming has to produce more correct code than two developers would have done programming individually. Mob programming would need to produce 5x the correct output of 5 developers. It just seems insanely unlikely that me and another developer pairing could be more than 2x as efficient as me on my own. I just don't miss that many things or get stuck almost ever.
People come to me for design advice, so I don't think having someone there to work with me on the design side would be useful either; I don't spend a lot of time flailing, I just write out really solid code, really quickly. Aside from that: I am fully in support of design meetings to sketch out architecture.
Today in ~6 hours of programming so far I would have saved about 4 minutes tracking down something that I typed wrong and that broke the tests that a second developer might (probably would) have caught. But another senior developer could have written code for 6 hours as well if they hadn't been watching over my shoulder. If we're talking about senior developers, how can you not assume they'd be able to create more code with a keyboard and no interruptions?
It really just doesn't make sense that experienced developers could possibly be more efficient if only one person is typing. Junior developers? Sure, at least that's a reasonable assumption. They have so little idea what they're doing, putting two inexperienced brains together on the problem might mean they produce more than twice as much, because they collectively know enough to work far more efficiently together.
But for experienced senior level developers? I think the burden of proof is on the advocates of pair programming. Extraordinary claims and all.
The main exception is when you have two distinct subject matter experts working together on a problem. Even then I like to have two keyboards, so it's not strictly pair programming, but collaborative/synchronized programming, with expected frequent questions and back-and-forth. I did that once recently when connecting a C/C++ low latency video and audio streaming library to Unity3d and C#; I worked with a Unity expert and while he wired up the Unity side I wired up the C++ side. I laid out what the Unity part needed to look like, and he told me how Unity interfaces to DLLs on Windows. We frequently bounced ideas back and forth but were working on different parts of the code. Worked great; had the integration working in a couple hours, plus or minus.