I haven't blogged in roughly a year. However, the InfoWorld article "Can TomEE save Java EE" brought me out of my blogging hiatus. Putting the title in context, driving controversy drives clicks and ad revenue. I grok that. The lead-in paragraph, however, talks about Java EE being frozen in time and those who care about appservers sitting in grey cubicles. After reading the article, I picked myself up and dusted myself off. Not from being knocked down, mind you, but from a fit of ROFL at the author's portrayal of Java EE. Now to defend the faith.
As a disclaimer, I lead the Java EE and GlassFish Server Product Management team at Oracle. As another disclaimer, I haven't worked in a cubicle in over 7 years 
There are two ways I am going to approach an opposing view - the Java EE programming model and Java EE implementations.
From a programming model perspective, there is no doubt that J2SE 1.4 + J2EE had its problems back in 1999-2003. It was complex. EJB 1.x/2.x and the persistence model spawned Hibernate and Spring. In 2006, Java SE 5 + Java EE 5 introduced annotated POJOs, where transactional business logic and persistence were greatly simplified. In 2009, Java EE 6 
added the Web Profile, enabling, for example, Caucho Resin and Apache TomEE to more directly influence the direction of Java EE with their own implementations. In 2013, on the verge of Java EE 7, the programming model is simplified even further with new and enhanced features driven by annotated POJOs. It doesn't get much simpler than
@Transactional @WebSocketEndpoint("/myEndpoint" ), does it? IDE's have all these wizards to help you become more productive, yet nine times out of ten I keep falling back to New->Java Class and tacking on the annotations I need. EJBs, Entities, Servlets, CDI - annotated POJOs. This POJO-based approach to development makes solving simple problems easy and the overall platform makes solving the wickedly hard problems possible.
From an implementation perspective, vendors have moved from monolithic J2EE runtimes to
modular Java EE runtimes that start in seconds, whether due to OSGi or other innovative modular systems. GlassFish Server, the Java EE reference implementations, introduced modularity in 2008. To put this in perspective, that's 2 years before Apple (re)introduced the world to tablet computing with the iPad. This was partially driven by customer demand and competitive pressures, partially by the introduction of the Web Profile, which required vendors to modularize their appservers if they wanted both full Java EE runtime and Web Profile distributions. Of course, Java EE implementations follow a bit behind the latest standard. Many organizations don't like change due to introduced risk and therefor continue run older versions of appservers. However, Java EE's backwards compatibility and well-defined deprecation strategy makes moving forward as easy as possible. Either way, vendors support them.
I have a tremendous amount of respect for David Blevins for his work in the Java Community Process and taking on TomEE as a Java EE compatible distribution. He also separated himself from the author's position in the article with his own post and takes the high road. Thanks, David.
To sum it up, Java EE is an easy platform to develop to, and implementations have become pretty darn lightweight and modular. What is frozen in time is the author's perception that Java EE needs saving.