Take a look at the internals of Hibernate and you'll see that they rely on a very substantial number of additional libraries.
It's not driven by the availability of more comprehensive standardisation efforts, since Hibernate was entirely unblessed by any standard (on the contrary, it has inspired many of the new features of the EJB3 specification).
No, framework creation is a bootstrapping problem. Sun made an incredibly good call when they made the *standard* J2SE class library so vast. With such a bulk of basic functionality already provided for you, it's easy to build upon it. The first generation of tools, bells, and gizmos, were basic library additions (log4j, dom4j and the like) - and these made extensive use of the standard libraries. They also provided an obvious starting point for future standardisation efforts.
With these gaps filled and de facto standard libraries added to the actual standard ones, it became practical to build substantial frameworks without having to reinvent a dozen new types of wheel in the process.
This ecosystem is what was missing - no substantial universally available set of library functionality for C++ existed. Instead dozens of platform specific or commercially restricted packages became available.
The creator of a new C++ framework must either roll together all of the basic functionality from scratch, or necessarily restrict the available audience to those who are able or prepared to accept their preferred subset of libraries.
Which is why I'm an ex C++ programmer, and a current Java developer.