It is about your skill set, not your title. I have met architects who were unbelievable coders. And ones who were nightmares. But every good architect that I know was also a good programmer. They might or might not actually spend much time programming, but they clearly could do it.
My understanding of the reason is that a good architect needs to be able to mentally connect every level from abstract architecture down to actual code. If you can't, then you'll eventually absorb ideas that sound good but don't really work in practice. (A random example that I dealt with was someone who didn't understand the latency added by sequential RPC round trips. And that the latency gets worse if you're making the mistake of using XML as your on the wire format...) And the failure of said ideas can always be attributed to programmers having screwed up your brilliant architecture.
For the record, this observation about architects is not original to me. I spent a year at Google, and in interview training we were clearly told that Google does not have a position for a non-coding architect. This is not to say that Google does not have positions for architects. http://research.google.com/pubs/jeff.html certainly wears the architect hat well, and is behind the design of large chunks of fundamental Google infrastructure. See http://static.googleusercontent.com/media/research.google.co... for an example of his showing that skillset off. But they have to code. Which Jeff does. A lot.
Not always, granted, but the format really can matter.
Grabbing a random benchmark, look at http://www.maxondev.com/serialization-performance-comparison.... It is in C#, but every language is going to give similar results. An efficient on the wire format like protocol buffers is a bit faster and a bit smaller than a sane text format like JSON. But XML is several times slower and several times bigger. He didn't test pretty-printing the XML, but that makes it several times slower and bigger still than plain XML.
This adds up sooner than you'd think. For a start there is a noticeable timing difference between an RPC call that fits in one packet and one that has to be split across two.
If you've got an application that spends a sizable portion of its time in serialization/deserialization, it is obvious that the format chosen will affect maximum throughput. (Many distributed applications spend most of their CPU time doing those two things.) It is harder for the format to have a noticeable impact on latency, but it both can and I've seen it happen.
The OP wrote a blanket statement stating if you follow this specific path you become "rusty" and ultimately end up not being able to code. He then states this becomes an issue when architecting solutions.
To me this is clearly non-sense as someone who's followed this path (and know others who have as well). Being an architect allows me to see the big picture and move the organization in the right direction (as we see it), while still being able to get into the trenches with my developers when something arises or help is needed. Granted, this is different for large enterprises but for startups/small/mid sized businesses, yes, us architects still get our hands dirty (or else we're irrelevant).
I said that there is a specific kind of bad candidate to watch out for who generally HAS followed that specific path.
I DID NOT say that ALL people who follow that path will become that kind of bad candidate. Or even most. Just enough that you can't afford to say, "This guy has been programming for 15+ years, is an architect, and sounds smart. I'll skip the programming test."
My understanding of the reason is that a good architect needs to be able to mentally connect every level from abstract architecture down to actual code. If you can't, then you'll eventually absorb ideas that sound good but don't really work in practice. (A random example that I dealt with was someone who didn't understand the latency added by sequential RPC round trips. And that the latency gets worse if you're making the mistake of using XML as your on the wire format...) And the failure of said ideas can always be attributed to programmers having screwed up your brilliant architecture.
For the record, this observation about architects is not original to me. I spent a year at Google, and in interview training we were clearly told that Google does not have a position for a non-coding architect. This is not to say that Google does not have positions for architects. http://research.google.com/pubs/jeff.html certainly wears the architect hat well, and is behind the design of large chunks of fundamental Google infrastructure. See http://static.googleusercontent.com/media/research.google.co... for an example of his showing that skillset off. But they have to code. Which Jeff does. A lot.