The comment by TS133T is right in that this article is comparing “apples and oranges”. Spring is an integration framework that can work with EJB2 or EJB3 (simply use a spring helper that gets the vendors JTA transaction manager or a spring helper that does a JNDI lookup). People question whether you can use them together. Of course you can.
It seems that the way the J2EE world works is as follows: old standards are always superseded by none-standard (and hence "proprietary") solution. As standards are designed by a committee they end up playing catch up with what looks is about to become the 'de facto standard' which the new "proprietary" solution that everyone is starting to use as it was designed to supersede the old standard. (Just how many books are there in 2008 on Spring? It is now supported by many proprietary application servers so I think that it would be churlish not to call it a defacto standard in 2009.)
It is a feedback loop though. Spring and Hibernate have learnt tricks from EJB3. They have rapidly taken on or integrated with the best parts of the standards. When this article came out EJB3 was new and on pre-release. It is now out of date as it is a couple of years on and Spring and Hibernate and Kodo have all moved on in that time.
I use the word "proprietary" in quotes above as it is something that the author talks about in terms of vendor lock-in. I think he over plays that fear. When you are dealing with big vendors like Oracle and IBM then you pay serious money and you suffer if you ever find that you want to leave your vendor. Most people that think about it really just don't “vendor lock-in” as a big problem when the solution you choose is pure opensource and designed to be embeddable or standalone - such as Spring or Hibernate.
With a FOSS (free and opensource solution) you have ‘lock-in’ in the same way that your locked into your choice of car. If your car suites you, use it, if not, then get another one. That's different to a mortgage. I am locked into my mortgage provider on a fixed term variable rate. If the base rate goes up my vendor puts up my monthly payments and there is a lead time (negotiating and signing contracts) and big dollar price (fees to arrange a new mortgage and penalties to exit my old one early) in switching over to another mortgage vendor. The mortgage has vendor lock-in. You would laugh in to say that I have that lock-in with my car. There is a cost to switch, but as I am free to use it, or free not to use it, and changing it is just the effort of enquiring a new one and getting familiar with its drive, handling and size when parking it. That is the same sort of cost experience when switching from an EJB2 to EJB3, or an EJB2 to spring, or from spring to EJB3. It called the cost of acquisition. Switching from one vendors standard compliant solution to another vendors solution to the same standard has the same cost of acquisition. You have to do a full regression test and both vendors have different bugs.
When you buy an 'everything in one single solution with support' from a big vendor, which the author recommends (to make your life simpler as it give you less choice and hence “complexity” than configuring spring) then what he is really encouraging you to do is to buy a mortgage. I would say that in the long run choice is just want you really want. Writing enterprise application is complex. There are no quick wins. I recommend you learn how to do it from the bottom up and inside out not from ‘point and click’ tutorials from a big vendor with a big cost to lock-in.