An architect care about the integrations, the extensibility of the system and so on. It is the developer who watch the code if you ask me. Of course, an architect will probably know how to code, but this is not his responsibility.
I'm stepping out of the narrow view that Sun/Oracle considers an architect to be. What the OCJMEA tests for is what is considered an Application Architect. Simply speaking, an Application Architect is someone who has enough technical skills to implement the entire application from scratch. The Application Architect may not be asked to code, or might code only the critical pieces, and be used to provide technical guidance to developers
However, there are other kinds of Architects and not all architects code. There are
a) Infrastructure Architects:- These people are to Sys Admin what Application Architect is to developers. Basically, an Infra Architect is someone who has enough knowledge of hardware, and configuration and setup of hardware to design the infrastructre of the application. As far as "coding" is concerend, Infra architect generally are experts in shell scripting
b) Business Architects:- Business architects are to Business Analysts what Application Architect is to developers. Basically, a Business Architect has the capability to take Business Requirements and generate System Requirements that are feasible with the technology stack used by the organization. They have enough business knowledge to prioritize projects to meet the business goals. Business Architects generally don;t code. However, there is a push in the industry to make Business Architects work in a BDD environment which requires some coding
c) Solutions Architects:- These people are more or less integerators. They have enough technical expertise to be able to figure out how to make systems interoperate, but generally do not code
d) Enterprise Architect: The Enterprise Architect is a strategic role. The EA seldom codes, and when s/he does it's only to make sure s/he is in touch with the code base, and not to work on a task. In a very large scale system, there would be dedicated Application, Infrastructure and Business Architects. In smaller system, the same person might play multiple roles. Enterprise Architect is the boss of all the other architects. S/he is making sure everyone is working together, and also helping the company make strategic technology decisions. The CTO is usually the Enterprise Architect. However, in very large companies, the CTO might be non-technical, and might have an Enterprise Architect under him/her
OCMJEA is really tailored towards Application Architects. However, it's beneficial for all the other kinds of Architects to take the OCMJEA. The other Architects need to be able to communicate to the Application Architect, and it helps if they have a good understanding of the Java stack. IMO, this is why Oracle doesn't mandate OCJP before OCMJEA. SO, non-programming architects can atleast get their hands round it.