Team work is much more natural if you are up against an external enemy in the broadest sense, like the military, farming, building an aircraft or a group of physicists taming nature.
It does NOT work for creative endeavours with a) a distinct amount of self-expression like programming or writing novels that b) also require enormous amounts of context in the working memory. This is why developers get into fights that easily.
(Please don't counter with "the humble programmer" and all that; we know, and Dijkstra himself wasn't humble. )
As long as everyone is "on the same wavelength" (I am sorry, I cannot quantify that better), it is basically effortless. You need someone to chop onions, and a few minutes later, they're just there. You sense that someone needs a filleting knife (they're just about to place a fish on a cutting board, or something similar that signals "this is the next tool needed") and you're close to it, so you make sure it is there for them (handle first, of course).
It is a very similar feeling to a well-integrated infantry unit making an entry into a presumed-hostile building, minus all the adrenaline.
This is why I've always found it frightening when some management type starts talking about the book Extreme Ownership. I am a veteran, though I was not SOF, and I have strong opinions about why military management mindsets do not translate well to the business world in _most_ cases. To be fair, I have not read the book, but from what I have heard from those who have read it, I would be wary of anyone trying to apply it to a software engineering shop.
The book is mostly about dealing with people rather than about engineering process, and I think the people aspects of a coding team and any other high performance team probably have a lot in common.
Both have completely different problems and advantages. The different (often complementary) tasks make all the difference here.
As a manager, I'm always on the look-out for tasks where I feel pairing may provide value. These are often moderately complicated tasks where I want a more junior team-member involved. Or, doing green-field UI work, I'll suggest one of the more UX-savvy developers pair with a small group of developers.
I have also managed people who just like to work together and they're free to pair and unpair on an ad-hoc basis. I don't care, as long as progress is being made.
Edit - I've never "paired" in the way you suggest in a sibling response (assigning a ticket to 2 developers).
Is collaboration / pairing part of employee evaluation in any way?
I'm not a vet (but my parents are planted in Arlington), but I've spent most of my adult life surrounded by them, so I've heard a lot of stories, and they are very practical, pithy applicable stories.
They often spring to mind, when I think about my work.
And we developers may not be thinking in military terms, but the chances are better than even, that the Corner Office is trying on a jacket covered in medals.
The good, is what the author was talking about. That team cohesiveness, that he disturbingly compared to being in a Borg Collective, is something that can't be easily quantified, but can amplify energy and positive morale. The Marines have known this for a couple of hundred years. Every Marine I've ever talked to, has described, almost verbatim, what he said. About how the squads act as a unit; almost without thinking. The results are tough to argue with. They are a highly effective fighting force.
The price can be burnout (as mentioned). When everything we do is being channeled and amplified, we have to be "on" all the time. We don't get that "five minutes of spacing out" between modules. In my case, that's absolutely required.
It's also a young person's game (like being a Marine infantryman). As I've gotten older, my personal process has become almost supernatural, but it has also become incredibly draining, and that "down time" is now no longer a luxury, but a necessity. On days that I have had some really challenging work, like chasing a pernicious bug, or setting up scaffolding for a new architecture, I can be absolutely flattened by bedtime. I feel as if I have spent the day digging trenches.
Also, I work best in my own head. I can create a pretty sizable architecture in my head, and don't need to write down a thing. That makes for very fast development, and tremendous flexibility. I can tear down an entire architectural construct, if it proves ineffective, and rebuild it, in a few minutes (in my head).
The minute I need to communicate it, however, that efficiency goes right into the bog.