You definitely get less code written than you would individually, but at the end of it everyone involved understands how the code works and why it conforms to the requirements which keeps your team's general knowledge high and turbocharges training for juniors.
It's also just pleasant to do a genuine team activity and have a laugh with people.
This is all coming from someone who greatly prefers working on their own to doing paring etc btw. It is nothing like the joy of getting your mind spinning at exactly the right speed, becoming one with the problem and smashing out a solution - so don't mentally compare it to that. It's much more like hanging out and brainstorming stupid ideas with your friends on the couch.
Is it generally (or in your positive experiences) done remotely, in-person, or could be either?
Here's some free marketing, I am not affiliated with any of these co.s: The best tool I've used for multiple users was CoScreen, because it shows everyone's cursors and allows simultaneous sharing of windows from multiple coworkers. So per that point in the OP that the major benefit is "trivia" knowledge, if you have one coworker who can quickly solve subproblem X from their terminal, and another who can quickly solve subproblem Y from their terminal, both terminals can be shared simultaneously and everyone can gain that context.
That makes sense, the "constantly moving around having side-conversations and whiteboarding things" being a good part of it.
After reading your description, I could see myself liking in-person mobbing too, and it really being a different thing than "pairing" (which I don't love)... but trying to do it remote sounds nightmarish to me personally.
I definitely think remote group programming is possible, but I reckon it'd be really hard to get right _starting_ remote, and it'd never be quite as good as in person is.
But, I often work on features that require the knowledge and input of many people. I lose a lot of time getting blocked on simple things by not knowing what I don't know, figuring out what I'm missing, figuring what to ask, waiting for an answer, trying to implement something based on a brief reply, etc...
The few times I've managed to gather a grop to do something approximating mob programming were incredibly productive. The whole time it was 3 people discussing the main thread of code and 1 person off on their own "fixing up some detail". Who was off on their own changed frequently. We were using VSCode Live Share and Live Share Audio.
8. Kinda. Only when the new ideas impact intra-team boundaries.
8.2 - No. Formal methods will one day be mainstream. We're still learning how to agree on what constitutes the optimal syntax for software. We are getting closer, then will come the optimal forms.
10.1 - No. The Unreasonable Man Theory applies here. It's not better for software that they have to encounter nor for the industry in general (not that I agree with any of the specific paradigms mentioned).
10.2 - I see it differently. Probably because developers require evidence that their life will be easier by adopting specific behaviors. That's hard to do over long periods of time, especially when the esoteric practices are both partly codified ad-hoc choices and partly useful. See item 8.
11. No. If your interviews are over 2hours, your 'loop' is reflecting problems in your organization. When you hire an engineering manager, do they interview every single person they are going to be managing to see if they like them before taking their new job? C'mon.
12. No. Just because it's a problem doesn't mean it's solvable or needs to be solved. Laying effect at the feet of the cause is reasonable. This response is uncharacteristically unreasonable.
13. No. This has already happened (Max 737), so not even then.