You say you can totally get behind that critique of OO. That doesn't mean you think people shouldn't use OO, right? Does it mean you think OO is a simple idea taken too far? Similar to the component architecture, you can use the mechanisms of OO to design things the wrong way with it. It takes experience to know that you shouldn't overuse inheritance, and experience to know that yes, inheritance is actually the easier way to deal with some problems after all and you shouldn't be avoiding it then. We're clearly still gaining experience with appropriate uses of the Zope 3 component architecture.
I'm not sure whether we're talking about the same thing, but to me 'adaptation of nothing at all' sounds like a utility lookup, and we have a getUtility() API for that and various ways to register utilities. Utility lookup is not adaptation, but is implemented on top of the same machinery as that gives us interface-based lookup and a generic pluggable registry. You seem to say that it's wrong to use this machinery as an implementation detail. Why? Perhaps because you haven't seen the utility specific APIs?
Basically Zope 3's component architecture is built on top of the interface machinery. Interfaces have several advantages above strings for lookup purposes - they support a notion of interface inheritance and they are API documentation. The adaptation machinery then provides for a system of registration and pluggability. You can suggest several different potentially simpler mechanisms instead to replace the various patterns, but are you don't sure you won't actually lose elegance and power in that simplification process?
The desire to have a generic lookup and registration machinery comes from our experience with pluggable applications in the Zope 2 context. We have found that we end up with a lot of registry and lookup systems there, all slightly different, and a lot of Python-based code that does all sorts of registration. A single explicit system for lookup and registration becomes very attractive with that experience.
I agree by the way that generic methods are interesting and we should be investigating how they fit in a Zope 3 context.