How many frameworks does one need though to design, document develop the same system and achieve same results? Ideally one. In practice, two or three perhaps, at least until the domain matures.
In fact, neither Zachman nor TOGAF are specific to EA.
Currently, most professionals don't use any specific framework; that is, we use bits and pieces of knowledge from everywhere and anywhere: Zachman, TOGAF... Value Chains, business models, operating models, balanced score cards, process frameworks, all kind of business methods, ITIL, COBIT...
Hence, some may even say that they don't need no frameworks. True. As long as the academia and the big firms cannot come with anything good, what can the practitioners do when there is such a demand for EA?
Without this framework, our volume of work would significantly increase and the results won't be similar, predictable or to expectations.
Each project is different. Yet we have the same project management method or framework. One has to use indeed own experience as well, on top of that.
Each enterprise has a product make and delivery function, a product development one, an HR, Finance and pretty much the same processes for accounting, payroll, marketing, sales, services...
Plenty of commonality as such between enterprises. That would be described by a business architecture framework like GODS. And that is why SAP is in business.
Besides an EA framework like FFLV describes how (work)Flows, Functions, Layers (technology and people) and stakeholders' View entities relate to each other in various artefacts and fit the EA whole. They can only link in one way. Hence, the EA metamodel is the same for all enterprises.
The fact of the matter is that the EA is the blueprint of the enterprise, nothing else. How it is used by strategists, operations etc is a distinct matter. As such, to my mind, the the requirements are the same for all EAs and EA frameworks but different for various stakeholders that use the EA, depending on the problem they solve and the domain.
Nevertheless, in practice, due to lack of definition, scope and the wide variability of EA job descriptions and expectations (such as architecting a Java application for instance!) many other questions can be asked that can be relevant to the job at hand but not relevant to the EA production.
The problem with EA is that not only it is inconsistently defined but there is a real distinction between what we think of it and what is demanded or performed in reality.