I think you've formulated the concerns quite well. Zope (2.x at least) seems similar in some ways to various Java frameworks where one is presented with a huge number of .jar files, a big configuration file with lots of sections, and documentation which glosses over the dependencies within the system. Consequently, as a developer, one has no confidence in being able to remove stuff which is either blatantly superfluous or worrying from a security perspective. Zope's "through the Web" management is nice, but I imagine that many people have wondered whether it could be detached and omitted from certain kinds of production systems.
Of course, one of the Python community's favourite megaframeworks, Twisted, went through its own process of decoupling a while back, and that may have made some of the components more popular. The prospect of having to adopt a huge blob which dwarfs one's own project is often something which invigorates the reinventive tendencies of many Python developers. Depending on or bundling some part of Twisted is better than having to monitor the effects of a complicated dependency on the whole thing.
From what I've seen, Twisted's refactoring is largely a failure. It's not compatible with eggs, and approximately zero people use the components separately -- everyone seems to still use the sumo distribution.
I think the only thing it solved is the complaint that it's not split up, I haven't seen that thread in a long time. It may have also helped a bit with the release management, but that matters to very few people. Supporting eggs would be a huge benefit to application and library developers, but they don't seem particularly interested in doing it.
I think Twisted's refactoring was kind of like Zope 3's refactoring, which happened in theory previously but no one used it. Actually getting usable isolated packages out of Zope 3 was hard, just for technical reasons, but also because the people doing the work didn't have much incentive to deal with the issues like getting the tarballs pushed somewhere and whatnot. Now they are taking a different tack with Eggs, and I think the result is potentially useful where the previous one wasn't. I think entry points are also really important here, because it's an actual novel feature which makes packaging matter as more than just a way to deflect criticism.
I also think people will really use the new Zope refactoring, if it is done well -- especially extracting small things (like, say, the transaction manager) instead of trying to extract "optional" things like the ZMI. The transaction manager is useful on its own, the ZMI is not. Similarly, the things Twisted should extract are things like the Deferred stuff, not the optional pieces like the protocol handlers. Right now I think the lack of a solid idiom for async programming (barring the use of the entire Twisted stack, or ad hoc callbacks) really keeps people from using that kind of programming in places where it might make sense.# Ian Bicking