Actually I think each of J2EE technologies  (EJBs, hibernate, whatever) are overused! I mean look at ADF BC for example. Compared to its simple and integrated approach all j2ee  persistence mechanisms such as ejb3 or hibernate seem very stupid and primitive. True it has limitations but it's ok for most projects, yet everyone seems to have this foot fetish for using this or that cool technology!!

Overall I'd say Spring still has the upper hand when it comes to non-ui stuff. For example  take a look at Mule ESB. See how beautifully it uses Spring. Or in other words, Spring is great for framework makers, but other polished and consistent technologies such as Seam are great for consumers of these ready-made frameworks. The point is, most people actually are just users of these frameworks, and mostly in creating web forms and such, so stuff such as Seam are completely adequate.

Also re linking statelessness to scalability, if your process is actually stateless or can be simplified to a stateless model then doing it statelessly is definitely a more scalable approach. That's how google scales. It's a huge cloud of stateless functional calls with no side effects. Read a few Erlang articles to understand that. They just scale it more and more buy add yet another big bunch of server  for handling even higher numbers  of stateless calls. But if your process is stateful doing it in a stateless manner will cause overhead since every stateless call has to fetch the last state every time from the db. Spring has stateful components too, it's just that SpringSource advocate statelessness.