I consider myself a pragmatist too but I've left Spring behind as of Java EE 5 and haven't looked back since.
My principal issue with Spring is that it is a single-vendor/single implementation solution and I don't see why I need to use it when there are equally good or better alternatives available (more on that below). That's hardly the only problem with Spring I see though. I also see issues with jar hell and configuration hell that I really hate. Harald Wellman did a great job outlining the problems some time ago: http://hwellmann.blogspot.com/2012/05/deconstructing-spring-myths.html.
Besides overlooking Spring's weaknesses, I think you miss a few key concepts:
Standards are for standardizing, not innovating. That's why all standardization processes take time. Now, Java EE 7 certainly was an exception in that it look longer than anyone really wanted. Historically, the Java EE release cadence has been about 2.5 years, which is great compared to pretty much any other standard out there. To boot, Java EE 6 was a pretty good release.
No good standard including Java EE is a walled garden. What this means is that standards aim to define a stable core for about the 80% use case. Beyond that, you are encouraged to use the ecosystem around the standard to meet needs outside the core. For J2EE/Java EE adopters, this has meant adopting solutions like Seam, Arquillian, RichFaces, PrimeFaces, Hibernate (in it's time), Castor (in it's time), XDoclet/EJB 2 (in it's time) and the other numerous complementary extensions to Java EE. As features mature and get assimilated into the standard, you have the option of porting over the non-standard parts or just leaving things alone for older applications in their maintenance cycle and adopt the standard for newer applications. Either way, you are fine due to the almost religious focus on backwards compatibility for pretty much all things Java EE.
A few of the other things you said can use some clarification, so I'll do that below:
* Java EE 7 haven't changed that much.
- You are clearly off base here. Java EE 7 is easily one of the most major releases Java EE has ever had. Just take a look at my slide deck on Java EE 7: http://www.slideshare.net/reza_rahman/javaeenext-java-ee-7-8-and-beyond. Most independent industry analysts have the same view: http://www.eweek.com/developer/oracle-delivers-java-ee-7-with-html5-support/. Just the support for HTML 5 WebSocket is hugely significant. In fact, I'd say the changes are far more significant than anything the Spring framework has had in pretty much the same time period.
* But what have to tell the people who placed their bets on EJB 2.1? There's really sometimes no way to tell them - hey rewrite your 1000+ session beans and deploy to Glassfish instead of WebSphere 6...
- Firstly, there's no need to port anything at all because of fact that containers like WebSphere most certainly work hard to maintain backwards compatibility. Secondly, EJB 2 is now a ten year old technology. I don't think anyone can expect a modernization from a ten years old technology to be painless. Thirdly, the component model changes that have happened from Java EE 5 to Java EE 7 and onward is really about meta-data. So in order to say port from EJB 3.0 to CDI 1.1 @Transactional components you primarily are just swapping annotations, not Java code. That's pretty much exactly the same story for porting between say Spring 2 XML to Spring 3.2 Java Config so I am not sure what your complaint there really is.
* CDI was revolutionary and was a great move. It required 3.5 years to spread it's @Inject and @Produces into other specs.
- If you are talking about the CDI aligment work done in JSF 2.2, JTA 1.2, Bean Validation 1.1, etc the changes again are pretty easy to adjust to and most of it has been possible for a long time via Seam 3/Java EE 6. For new specs, the point is obviously moot since they did not exist when CDI 1.0 was standardized.
* Security - how using "Vanilla JavaEE" is going to protect my future when I don't have decent Security technology?
- You are way off base here too. There are actually several good options. The first is container security. Here's a decent article showing you the basics on GlassFish: http://blog.eisele.net/2013/01/jdbc-realm-glassfish312-primefaces342.html for authentication. Authorization is just a matter of using a few annotations like @RolesAllowed. If you really need something more elaborate/portable there's always PicketLink and Shiro. Both work well with CDI.
* So sticking to non-standard, Github based Spring portfolio is much more reliable than waiting for JavaEE 8. But I'll still not be able to download TCK for JAX-WS, I still won't be able to tell which one of 10000+ tags in java.net SVN repository is "the" version I should file a JIRA issue to.
- This is perhaps the clearest example of frivolous nitpicking, bias or resistance to change on your part. For most developers, getting issues solved is a simple matter of logging a JIRA issue against a GlassFish version. The engineers involved figure out the rest and they are damn good at it. The vast majority of developers go this route and could care less where source code is stored.
Reza Rahman | Java EE/GlassFish Evangelist
All views voiced are my own, not necessarily Oracle's.