I agree completely, I think this is really the distinction that is lacking when people talk about superstar developers. Most aren't developing much of anything in terms of raw implementation, they're redesigning existing architectures, theorizing new approaches, bridging domains, etc.

Those skills are often tied to specific domains that are not quickly transferable so what talented engineer A does efficiently or makes them a superstar is specific to engineer A. Talented engineer B probably does something a bit different or has their own sets of expertise they're superstars at.

There are a lot of misguided organizations hiring on the wrong premise though, that there are developers who just churn out implementations at 10-100x speed so they can reduce their workforce. What they should focus on is engineering talent that makes sure they're tackling the correct problems and focus on the right solutions to those problems as opposed to something silly like developer velocity.

You explained the fundamental philosophical divide in software development today. One group sees development as a process of production. They still think of developers as people who produce code. The other group sees software development as a process of problem discovery and definition. Programming is an exploratory learning process that, at its best, refines and condenses human concepts and symbols into concrete representations automated by a computer. In my opinion the latter group will always outperform the former (barring massive resource discrepancies) because they have a more powerful theoretical grip on their activities.

A great design/architect will mean you need to write 1/10th as much code.

Well, not really but maybe 1/2