When I look at great developers, they can not only build things without taking as many dead ends but they can explain why and share their reasoning with the rest of the team effectively.
The very best can not only complete their own tasks well but their "prowess" (for lack of a better term) is witnessed and people seek out their advice.. therefore making others more effective too.
The (unsurprising, really) backlash was not because their work had slowed down (in fact it solved many problems) but because their non-work was impeded. Flash was a bit dodgy, so browser games were out. Their favorite torrent programs didn't work in Linux. Of course, they couldn't use these reasons when complaining to the boss, so there were some amusing verbal gymnastics....
Another interpretation of this is that 10x programmers get dragged down when they have to work on teams that are too large or don't grant autonomy.
Yes, if you have a small team of say 10 people, a very competent lead engineer can make all the difference by setting up proper testing, SCM, CI, etc. i.e., by choosing the right tools and people for the job.
However, as soon as you have a slightly larger team, these decisions will usually not be made by one single person. If you have a large project with dozens or hundreds of engineers, you'll have dedicated teams for some of these tasks, making their own desicions.
In my opinion, the most important thing then is to spot anything that will make things go haywire, communicate them and convince the right people that this has to be fixed. If you force a new porgramming language onto the whole team because it makes you, the 10x engineer, more productive, you might face endless discussions, additional training costs and a big backlash ("why do we need this now?") from the team.