Wow, someone who actually knows what they're talking about when posting here. That's kinda like someone RTFA.
Hibernate is good by me, though I've enjoyed using Kodo/BEA/EJB3.0 in the past for OR mapping as well. Even old school JDBC in session beans is often good enough for most things.
Personally I usually hate Spring IOC because all of the simple compile-time problems with typos and capitalization on imports turn into runtime configuration problems because those typos now exist in one of 500 random XML files (and the last one that you would think to look in). That and you often have a billion stupid interfaces with one and only one implementation class. Add to that NooB's who think everything has to be a session EJB with still another Facade EJB in front of it because they think Rod Johnson said it was supposed to be that way, and you realize that frameworks aren't necessarily going to make the architecture better, they just create more places for dumb developers to screw up (not that the original poster is doing that). Spring works well for developing a system that needs to support a lot of app server specific junk on multiple app servers (like LDAP single sign on stuff and JMX voodoo), multiple implementations of the same interfaces (like a product company writing client specific stuff), as well as for transaction management beyond pure JDBC transactions while running standalone JVM's outside of an app server. Almost no one needs that, so usually Spring is more hassle than it's worth. (particularly when trying to configure in Axis2 web services and other solutions that like to roll their own classloaders).
Good software engineers know which competing frameworks to use, when each is appropriate for the assigned task, when to forego a framework and roll your own. Good architects know all of that, plus when the developer is designing a Rolls Royce when a Toyota is appropriate, which frameworks play well together, which is appropriate for the developers on the team both present and future, as well as when architectural decisions should be made, because switching frameworks or architectural refactoring midstream becomes insanely expensive and wasteful. Bottom line -- code reuse in and of itself may make the coding easier to implement and maintain, but having a sound architecture appropriate to the project is even more important. Just using Spring, hibernate, struts, axis, GWT or whatever flavor-of-the-week framework is popular and throwing together some junit and canoo tests doesn't mean that your solution doesn't flat-out suck. If anything, the richness of frameworks borne of the maturity of a language requires more wisdom and discernment, not less.
As to the actual post itself -- It appears the dev isn't very familiar with the frameworks chosen, and needs to do a little digging in the mailing lists and doc. There's very few things that aren't possible with Spring/Hibernate with a little ingenuity. If the problems are with technical limitations of Spring Web Services such as WS-ReliableMessaging or WS-StandardOfTheWeek then use contract-first with Axis2. It's easy to swap it out.
When we write programs that "learn", it turns out we do and they don't.