I suppose whether or not I agree depends on what you mean by complicated: there's complexity of an algorithm implementation and there's complexity of program structure.
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.
That is how I have it as well. With our projects usually the architect would write the framework of the product at the beginning of project, almost being the only developer on the project.
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.
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.