This doesn't include paper architects, which are pretty much salespeople.
I would like to hear other people's thoughts on this - this is the way that I have always handled projects.
I would think that you'd want an architect to work on non-tight-loop, core-to-the-control flow complexity, and leave the optimization of tight loops and such to people with more time to focus on the details of that (eg, what processor is being used), and instead work on the complexity of the control/data flow abstractions, which is what he already knows the most about, having designed their architecture.
This also keeps his role as central organizer of the code and flow through it, rather than having his time sidetracked (partially) by other concerns.
As other developers start getting on the project he guides them where their code should live, and he start to disengage writing and serve more in a guiding role.
If instead he dreams of becomming a manager or architect, then he would actually not be coding the most complicated parts, and make sure to keep himself off the critical path of the project, so as to free up his time, so he can spend his time helping his colleagues and clearing the rocks in their path.
Also as a manager or architect, you better get used to constant interruptions, degrading the quality of code you can generate. So think hard before assigning that critical section to yourself.