As a teacher I never assign group projects for their own sake. If something makes more sense being done in a group, we do that. If it's better done by individuals, we work alone and share our results.
Sadly, most managers are of the wait until there's a fire type. These are not really managers except in title as they simply are not managing anything.
Fundamentally, the problem was trust -- the management didn't trust the engineers, so they micromanaged them poorly while invoking "agile" to make heavy management somehow seem like a populist movement for the "team". And because the team was micromanaged and not trusted, motivation was low and the output was poor, which just made the problems worse.
(Not surprisingly: the company recently just laid off the entire staff)
The only thing the Unruly team is dogmatic about is delivering valuable software. The techniques they talk about are simply this - techniques.
In my work as a consultant there is rarely a 'one-size fits all' technique to developing a feature, but knowledge of several approaches is very valuable.
This is the purpose of the article - to allow you to consider the addition of 'mobbing' to your existing approaches of single development and pairing
I know this isn't exactly the same thing, and I try to keep an open mind on these things, but you could just as easily call this "programming by committee". We all know how great anything described by "X by committee" turns out.
There's nothing wrong with gathering a few people together to work on a thorny problem, but that sort of gathering has to happen organically. When people trying to sell management books turn this sort of thing into a buzzword, it just ends up being cluelessly applied by some starry eyed junior manager that has found a shiny new hammer and the world looks like nails to him.