That's been debunked by examples where hiring (literal) team players that are not shining on their own enhances a team above the level of an 'all-star' team. So why do we keep repeating this nonsense?
It'd guess it's because a) it lets us all think we are in the "rockstar" category, which is pleasing, and b) it lets us avoid all sorts of difficult thinking about the system that actually produces the work, and c) justifies unequal rewards, which is entirely useful to the people receiving the rewards.
It's the same reason the myth of the 10x engineer is so popular. I've worked with some people who certainly thought they were the 10x engineer. As far as I could tell, they were just showboats who did highly visible work, leaving little things like technical debt for others. Or the "brilliant" engineer who make things that require high cognitive load to understand, instead of doing the extra work to make them clear. [1] Or who shirk the work of supporting colleagues and building strong teams.
So basically I think these are the people who optimize for the visible success metric, not the ones creating the most value.
[1] Just this week a friend took over responsibility for an internal build system. The previous author had written it in JavaScript. Except that he was really excited about functional languages, so he wrote it in a highly functional style incomprehensible to anybody not used to it. Now this either needs to be mostly rewritten or anybody who wants to work on the build system needs to spend 6 months learning Haskell first. I'm sure this guy looked productive and got to sound brilliant in meetings, but a better productivity analysis would include the significant costs he imposed on others.
Your question is a good one. The zeitgeist in the US has been for years that we at are all the same and "rockstars" just try harder. In reality, not everyone wants to be that, and not every team needs that.
It's the same reason the myth of the 10x engineer is so popular. I've worked with some people who certainly thought they were the 10x engineer. As far as I could tell, they were just showboats who did highly visible work, leaving little things like technical debt for others. Or the "brilliant" engineer who make things that require high cognitive load to understand, instead of doing the extra work to make them clear. [1] Or who shirk the work of supporting colleagues and building strong teams.
So basically I think these are the people who optimize for the visible success metric, not the ones creating the most value.
[1] Just this week a friend took over responsibility for an internal build system. The previous author had written it in JavaScript. Except that he was really excited about functional languages, so he wrote it in a highly functional style incomprehensible to anybody not used to it. Now this either needs to be mostly rewritten or anybody who wants to work on the build system needs to spend 6 months learning Haskell first. I'm sure this guy looked productive and got to sound brilliant in meetings, but a better productivity analysis would include the significant costs he imposed on others.