The Zope Component Architecture is, loosely speaking, a registry for components.  These components are defined in terms of their associated Interfaces.  The reason why this is useful, is that the registry provides an easy and fast lookup to find implementations of various interfaces, and a way to specify relationships between components of the system being developed.  Interfaces are abstractions of their implementations, meaning that it becomes simpler to maintain and extend functionality.

Where is the ZCA used?

 The ZCA is used wherever a pluggable interface is needed.  For example, views on data models: to define a view, it is first registered with the ZCA. When the Grok framework receives a request, the request URL maps to a data model, and an associated view is looked up by name in the site registry.  Similarly, event handlers may be registered with the ZCA and an appropriate event handler located later, using the site registry.

Note that this behaviour is very different indeed from most other web frameworks, which use "routing" to directly identify a view. Routing does not usually identify a model, but provides the means to do so, and it's up to the view implementation to locate the needed data.  Zope (and Grok) works differently, using "traversal" to identify both the data model and the associated view, and this can greatly simplify code.

What are the advantages of this approach?

In a nutshell, efficiency, simplicity, scalability and flexibility.  By using a common and uniform way to glue bits and pieces of the framework together, the way these things fit together is formalised.  Because any component may be easily replaced by another by simply registering the new component with the ZCA, the entire framework becomes pluggable and extensible.

A further distinct advantage is separation of concerns.  By building your component to meet the specification of a public interface, none of the implementation detail beyond the interface itself needs to be exposed. On a practical level, this means that your source code is better organised, better documented and more managable.

There are sure to be those readers who have run into circular dependancy problems while coding web apps.  The use of global or local utities and adapters completely circumvents this problem.  We will show how views may be shared across multiple URL's with the greatest of ease using the ZCA.

Are there any caveats to using the ZCA?

Sure there are.  No architecture is without faults.  One problem is that one can easily get carried away.  Not every function needs to be a pluggable utility or registered with the site registry.  It is quite easy to end up adding rather than reducing complexity (AKA "Death by Abstraction"). 

This is an easy mistake to make for developers new to Grok; as they start getting familiar with and excited about concepts like utilities and adapters, they immediately try to apply the concepts to everything they do (its so cool, right?).

There is also quite a steep learning curve and conceptual hill to climb before one can become really productive.  One first needs to understand the types of components supported by the ZCA and where best to use them.  There are a huge number of components in the Zope Toolkit, and an awful lot to learn about.