This article by Microsoft Patterns and Practice people is a good example of what I often talk about, that a software architect needs to be hands-on. The credits here show a large number of people, that isn’t necessarily needed to architect a solution properly, this is probably just how they collaboratively put it all together.
Not understanding enough about all aspects of the architecture is often the cause for things going wrong down the road. Such risk is mitigated if teams dive into all corners of the problem and solution domain. As an architect, if folks try to take your ideas in unintended directions you would at least be able to spot that and assess any potential issues or risks that may result.
If the architect isn’t hands-on, he/she is not well equipped to perform such assessment adequately, he/she would have to go by what is being told in blind faith. When that happens then one of the main objectives of architecting a software solution, risk management, becomes weak.