Bom, li o artigo e discordo de alguns pontos.
“Spring Always Depended on Java EE” - discordo devido a minha própria experiência profissional com Spring. Sim, há vários wrappers no Spring que envolvem componentes do Java EE como JMS, JPA, Transações, etc, mas é importante lembrar um ponto aqui: estes wrappers nunca foram o core do Spring ou a razão de adoção principal do framework, mas sim o seu excelente container de injeção de dependências E o fato de podermos usar AOP sem muita dificuldade (AOP ainda não está no Java EE até aonde pude observar com tamanha facilidade quanto a que encontramos no Spring).
Na realidade, eu usava o Spring sem Java EE desenvolvendo aplicações desktop. Como meu cliente possuia inúmeros ambientes de deploy, o Spring caia como uma luva, porque bastava eu alterar o xml de configuração de beans, sem a necessidade de recompilação e voilá, configuração nova prontinha para o “ambiente hostil”. Até tentei simplificar o Spring em um experimento chamado miocc (http://miocc.itexto.com.br), mas no final das contas, me rendi ao container do Spring que era anos luz superior e sempre muito, MUITO leve. Sendo assim, discordo: o foco do Spring é o seu container DI E AOP, que ainda são excelentes E, mais interessante, oferecem uma flexibilidade de opções de configuração (XML, Anotações ou Java) que o Java EE ainda não oferece.
“Annotations were a game changer” - Se for pra pensar numa evolução do Java que mudou tudo, sem dúvida foi a introdução das anotações. Com elas se tornou possível incluir metadados nas nossas classes Java e uma gama monstro de soluções surgiu via reflexão. Infelizmente, dentre as novidades que vieram com as anotações foram os “xiitas anti-XML”. Enquanto há documentos XML monstruosos cuja manutenção é um inferno, muitos vendam os olhos para o fato de que também há monstruosidades usando anotações e com um “probleminha” a mais: ao contrário do XML, você não consegue externalizar anotações sem a necessidade de recompilação. No meu caso, em que era feito desenvolvimento de um produto para diversos ambientes, adivinha quem ganhava: anotações ou XML? XML NA VEIA.
(Outro ponto importante em prol do XML. No ambiente de produção, o analista de sistemas não pode contar com a recompilação do sistema, mas sim com alteração de configurações externalizáveis. Imaginem como seria um ambiente sem estes arquivos.)
“CDI closed API hole” - De novo discordo porque no caso do CDI, este está muito mais focado em aplicações Java EE do que “não EE”. Além disto, é interessante observar alguns fatos: o primeiro deles é que CDI é uma abstração em cima do conceito de injeção de dependências, assim como o JPA para ORM. Consequentemente, temos aqui o menor denominador comum. Sim, o Weld é lindo e tal, mas baseia-se em dois pontos que não são a última bolacha do pacote: auto wiring e anotações apenas. Quem já trabalhou com auto wiring sabe dos problemas que costumam acontecer quando o sistema cresce, e com relação ao uso exclusivo de anotações, como mencionei acima, há o problema de não serem fácilmente externalizáveis. (tenho 25 páginas de argumentação a este respeito http://www.itexto.net/devkico/?p=859 
)
“App Servers got their act together” - as pessoas não usavam Spring por causa do tempo de boot dos servidores, mas porque o modelo de desenvolvimento era superior por ser baseado em POJOs ao invés da implementação daquelas interfaces melequentas. Sim, havia o ganho do tempo de boot, é claro, mas convém lembrar que mesmo hoje, com servidores que startam em segundos, desenvolver e testar contra estes servidores, versus desenvolver e testar versus POJOs não é só mais eficiente na questão tempo, mas performance também.
“Arquillian made a mock of mocks” - ai há um problema na argumentação sério também. Bill Burke diz que um dos fatores da “derrota” do Spring é que um outro projeto, fora da especificação Java EE surgiu??? E outra: quem aqui adotou o Spring ao invés da especificação padrão Java EE por causa das suas funcionalidades de teste que atire a primeira pedra. Nunca encontrei ninguém.
)