Maybe every architect should be capable of coding some basic stuff, and adding clustered indexes to tables; and maybe he should do it from time to time, just to ensure that he really retains the ability. Necessary work like reviewing security, logs, and audits isn't just tedious administrative stuff - and if you have it done by someone who thinks of it that way it will not be done properly: you will not have security, your audits will be worthless, and amazing things that should cause immediate diagnostic action followed by remedial work will be missed in the logs.

Devising a new architecture for something to replace the way it has always done can be quite exciting. Applying a well-known architecture (or system design pattern) to meet some requirement that isn't too different from things that have been done before using that architecture/pattern is what is often necessary, though unexciting; but if that "not too different" turns out to be just a little optimistic that too can become quite exciting, and if you have decided to shoot for a 5-fold improvement in efficiency of the software the changes to the architecture can be pretty exciting in that case too.

I tend to agree that what the article suggests is about talent levels and responsibilities is actually about job choices - and I would go further and say that when someone in a senior position makes job choices that divorces him completely from basic DBA of Developer activities he risks rendering himself useless and ineffective as a system or application architect or as a database expert. If real security is required, a real security expert is needed - and the system architect had better be able to understand what that security expert says, the security expert had better understand how privileges, capabilities, and permissions work in the database, at the app's UI, between app components, in filestore, and between the users, and both of them should understand how to change those things - which they won't if they don't understand for example how the database GRANT primitive works because detail like that is so far below their altitude than they obviously don't need to deal with such details, the junior DBA can do all that, or they don't understand how the app is used, that's up to the junior guys who directly use it. So the architect has to be a generalist - he must of course be an expert in system architecture and design or in application architecture and design or in both, but he must also be a jack-of-all-trades because he can't have that expertise without understanding what the developers and DBAs and users are doing.