For better or worse, I think the idea of the surgical team runs counter to the prevailing egalitarian spirit in software development. Personally, I think there are some projects that are better suited to it than others. For example, I've been involved with technically-demanding projects that suffered from the "too many cooks in the kitchen" syndrome that the surgical team approach addresses. On the other hand, there's plenty of more mundane feature development work that probably doesn't benefit nearly as much from that approach.

One criticism that I would expect some to make against the surgical team approach is that it doesn't help to develop more junior team members. From personal experience, I think it's actually a good way to develop junior team members. I learned the most when I was around more technically experienced team members even if they were dictating the breakdown of the work rather than when I went off on my own to develop less technically challenging features. Some mix of the two is probably ideal, but I think there's some lack of appreciation for the benefits of a surgical team environment.

Many open source project are functioning in this way. In companies, it's more common in the initial phases, but when you just maintain code, it wouldn't make much sense.

Isn't this how most companies are set up? If the architect/technical lead is the surgeon, then the junior/mid level developers are the support team.

Some companies certainly, but far from all. Some place I've been the architect/technical lead doesn't actually do much day to day coding. They're more responsible for defining tasks, and making sure they get delegated and completed to a high enough standard. Sure they'll keep an eye on the code and come with suggestions, but they only very rarely get their hands bloody (to extend the metaphor).

Simple: it is great at solving problems, but not so great for middle management.