Absoluut waar, maar dat komt denk ik ook omdat in die branches er ook een geheel eigen skill nodig is voor het uitvoeren van de architectuur zeg maar.
Bij development is dat niet zo.
Het uitvoeren, aanbrengen, dupliceren, etc is triviaal. Dat doet de runtime, de compiler en het copy commando.
Elke developer is eigenlijk al zijn of haar eigen mini-architect. Het is daarbij wel handig als er 1 of enkele lead developers zijn die de wat grotere lijnen in de gaten houden, maar dat is niet hetzelfde als de analogie met andere branches proberen te bereiken en architecten neer te zetten die alleen maar mooie UML diagrams tekenen.
Hierbij is dan niet zelden de gedachte dat de slimme architect deze UML diagrams "volledig uitdenkt" en de "domme" programmeur (code monkey, whatever), deze blind omzet in code. Dat is natuurlijk onzin. Als dat inderdaad mogelijk zou zijn dat kun je ook een compiler schrijven die UML omzet in uitvoerbare code. Als de architect op een dergelijk niveau UML diagrammen zou schrijven dat het uitvoerbare programma's worden, dan is deze persoon gewoon een programmeur die alleen UML gebruikt in plaats van b.v. Java of PHP.
Gelukkig dat je vrouw niet zo'n architect wil worden

Zoals gezegd, ik heb het veel bedrijven zien proberen om zo'n positie te realiseren, maar eigenlijk nog nooit gezien dat het waarde toevoegt.
Hoe ik zelf de progressie zie is
Algemene prutser - code wat zelf als hobby, geen opleiding
Junior developer - opleiding (meestal HBO, kan ook WO), en begint pas
Mid level developer - Junior met jaar of 4, 5 ervaring, kan redelijk complexe taken zelfstandig uitvoeren
Senior developer - Stapje verder dan mid level, kan nagenoeg alles zelfstandig uitvoeren
Lead developer - Weer stapje verder, kan niet alleen alles uitvoeren, maar stuurt ook team aan kiest technieken, kijkt naar grote lijnen wat betreft scalability, onderhoudbaarheid, etc
Als je dan nog verder gaat is wat soms wel eens "rockstar" wordt genoemd, maar dat is niet zo'n hele goede naam vindt ik. Los van de naam betekent het dat je bekend bent in de technische community; een bekende blog hebt, jouw artikelen dikwijls naar gerefereerd wordt, dat je wellicht spreekt op conferenties, je vast en zeker een goed lopend eigen open source project hebt, of dat je committer bent bij een groter open source project, en dat je (indien van toepassing) invloedrijk bent bij de totstandkoming van specificaties op jouw gebied (zoals b.v. w3c specs, C++ iso specs, Java JCP specs, etc).
Natuurlijk heb je in dat laatst genoemde niveau ook weer diverse treden, maar in zekere zin ben je dan bezig met je eigen "branding".
Zoals je al zei, het levert je niet direct wat op. Je krijgt niet betaald voor de opname van een patch in de Linux kernel, maar naarmate je dit meer doet stijgt wel je eigen bekendheid wat je weer zeer van pas kan komen bij sollicitaties of onderhandelingen met technische klanten.
Reken maar dat 1 van de bekende committers van b.v. Postgres meer gevraagd en gewaardeerd wordt voor consultancy opdrachten waarbij Postgres een hoofdrol speelt dan Peter van het Hek die 5 jaar iets bij De Smit automatisering heeft gedaan met DBs
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.