Sorry, I don't really buy this one.

For projects that depend on solving simple problems, that is, those which any competent developer could solve well, then sometimes communication and teamwork are probably the limiting factor. Of course, even then, it is possible that a "10x developer" (a crude simplification, but it will do) could do the work of 10 1x developers and without the overhead: one such person will be 100x more efficient at internal communications and 10x more efficient at external communications by default, so your "10x team" members will each need to be 10x more efficient based on their better communication skills just to break even. Unless your 10x developer is particularly bad at communicating -- and in my experience, the opposite is frequently true, because that is a big part of how someone becomes the mythical 10x developer -- I'm not sure you'll ever hit that.

Then you have to look at projects that depend on solving hard problems, those where developers below a certain level of skill and/or insight will not be able to find an acceptable solution. Here your overall performance is at least partly determined by how many developers you have above that threshold and how well they communicate. This is why having a crude 1x vs. 10x approximation isn't very helpful in my view: it's always a sliding scale, and maybe a couple of 3x developers in the mix is all you need for the team as a whole to get over a tricky hurdle.

In the limit, for projects that depend on solving a really hard problem, your bound may simply be the maximum skill/insight level of any individual on your team. If you don't have anyone good enough, you can't solve the problem at all.

On top of that, in the real world, few products and services depend on solving a single problem with a single monolithic team. You are going to have multiple problems to solve, possibly by different groups of people, which then need to be co-ordinated in some way. In other words, your overall team is going to have cliques, possibly on several levels of nesting, and you need to worry about the performance of each clique, which in turn depends on the talents and the team-working within that clique as set out above. And on top of all of that, you have to worry about communication between cliques, integrating their work to produce the overall product or service. And then you have the fact that membership of cliques is not constant: staff will come and go, sometimes people will change role to make better use of their skills and experience or simply to keep their interest level up in a long-running project, etc. This is why good managers, co-ordinators like software architects, and technical leaders are so valuable.

In short: I think the whole premise of this article is a gross over-simplification based on some dubious basic assumptions, starting with the fact that those people who lift the team in various ways aren't actually the very 10x developers you're talking about. If all you do is develop software that solves simple problems with small teams then maybe the premise is true to a point, because you don't take much advantage of the stronger developers. Plenty of real world projects are like this, of course. However, I expect few people reading HN want to work on them, and plenty more real world projects need more. No amount of hiring chummy people with mediocre skills is going to make those projects succeed.