Lack of full DI support has really hurt the EE platform. I really felt this pain while on the JAX-RS expert group and leading the JBoss Resteasy
From the JAX-RS EG/JSR perspective, lack of DI hurt us (IMO) because we needed fine-grain configuration and injection of plain Java objects. Particularly for adding support for JAXB. What ended up happening is that an ad-hoc, use-case specific model was introduce that was specific to JAX-RS. (ContextResolver). It would have been so much better if we had Web Beans available to provide this fine-grain injection rather than writing our own ad-hoc solution.
From a RESTEasy perspective, I needed a way to configure the framework. What I didn't want was to have a Seam, Guice, or Spring dependency enforced on Seam, Guice, or Spring users. I also didn't want to implement/maintain/document 3 different ways of bootstrapping and configuring RESTEasy all just to do some simple configuration.
Finally, the last amazing thing about the specification is that because it permeates into specifications like EJB and Servlet, future domain-specific injection frameworks like JAX-RS could easily be integrated in a portable manner into all of EE fairly easily because Web Beans provides the facilities and integration points to do this. I'm really excited about re-implementing Resteasy in terms of Web Beans and see how this could affect my extensibility.
Java EE needs to become a living breathing specification that encourages innovation by providing the integration points and facilities for new third-party frameworks. I believe Web Beans can be a large part of the story here. Combined with the pluggability aspects that other JSRs like EJB, JCA, and other specifications are doing, EE 6 could add years to the viability to the Java EE platform.
JBoss, a division of Red Hat