That's exactly what is not implied. The point is not the tech. Any tech can be good.
The thing is that while you can be a brillant programmer who makes super smart design choices using the better techs, it's not enough.
If you create a smart and powerful architecture but you fail to document it and then convince, train and onboard the rest of the team, you may be a brillant programmer but you are also a bad team member.
Those people are not wrong, they can be very productive or useful, but you have to identify them and make them work alone, because that's where they strive. And that's where I agree with you when you say it's a management issue.
Those people are frequently really good at abstract thinking, which is a great power for a programmer but can be an issue when you have to communicate clearly a train of thought with other people. In my experience, this can be a root of conflicts between people that otherwise have a good relationship, because it ultimately leads to programmer A thinking that programmer B is over engineering everything and programmer B thinking that programmer A is too stupid.
> When devs like the author do manage to single-handedly deliver entire codebases (e.g. over long periods of time), they are typically just as bug-ridden and unmaintainable as what the "rock star" devs produce.
That's why devs like the author are never asked to single-handedly deliver entire codebases but to bring their skillset to a team that is tasked to maintain long term code base. And maintening long term codebases for a team may imply doing things the boring and simpliest way.