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.
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.
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 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"