Some thoughts;

1. At some point in the 90s there was an "Extreme Programming" movement, or XP as it were. I distinctly remember the dogma built up around this, to the point where I started being forced to do pair programming in a formal sense, all day. Thankfully I just quit. I guess I prefer my coding to be less than extreme.

2. As others have mentioned, short term pair programming (never works >2 imo) is an excellent way of transferring knowledge (a model) to someone else, or to make progress on complex problems when you are stuck (the rubber duck effect is real).

3. I'm afraid I really must be getting old as I've never heard of "mob programming", and to be frank I've spent the last hours being horrified that such an idea exists. I guess in a way code reviews can be like that sometimes. lol.

Yeah but just about nowhere did XP properly, though many places claimed to in the late 90s, early 00s whenever it was the extreme hotness. It was one of those peculiar cults everyone talked up, but just about no one understood or had even read the book.

One place I was at did everything, including onsite customer etc. In context pair programming managed to stay enjoyable for the entire time and they didn't seem to have high turnover. It actually kept on feeling more productive. I was there around a year (contract). I never encountered it again so can't comment if that was sheer luck or the people (or project) they happened to have...

There was a spell when every job ad seemed to want to claim it, but basically picked pair programming and two to five of the bullets and handwaved or ignored the rest. Or merged it with plenty of old school waterfall project management, Gantt charts, random bits of UML or some other tangent. I guess I'm not surprised so many ended up hating everything around XP and pair programming as it took many forms. It made for a few surreal interviews after that one encounter of an employer who'd adopted it fully and properly.

Any practice which almost no one gets it right, may be there is something inherently wrong about the practice that so many smart people are failing to implement it right.

I've done non-forced pair programming for suitable tasks that were really math heavy in a controll algorithm where I essentially double checked the math. Worked that time really well but always doing it would make me hate my job.

In my experience pair programming works wonderfully for short, intense and complex problem solving scenarios. The extra pair of eyes and a second brain gnawing at a nasty problem is a good way to augment each other's capabilities.

In fact, I dare say that pair debugging is where the practice really shines. Doing it all the time, for all tasks? That won't fly.

I’ve only seen mob-programming to be adopted by teams of junior-slackers, but YMMV

Pair programming was never intended to be a full time mode of development. Half an hour once a week (or whenever) is good enough, and can help with mentoring junior developers. But it is really moronic to do that full time.

"intended"? By who? Based on what?

I worked at companies that had full time pairing and it worked well.

When you tried full time pairing, what were the issues you observed that made you conclude it was "moronic"

.. by the people who started it and popularized it. I have never tried it full time because it's obviously patently moronic to do it that way, and would destroy all enjoyment of the job. I have worked with highly talented developers and can not recall any one of them wanting to pair full time. I have received huge benefits from occasional pair programming with senior developers in my less senior days. However, I need to try full time pair programming as much as I need to try jumping into a fire to verify that it's not a smart idea. If my employer forced me to do that I would quit on the spot.