First, let's set up some vocabulary.
Standard - "regularly and widely used" (http://wordnet.princeton.edu/perl/webwn)
Proprietary - "Something proprietary is something exclusively owned by someone, often with connotations that it is exclusive and cannot be used by other parties without negotiations." (en.wikipedia.org/wiki/Proprietary)
These are appropriate definitions of some key words you've used in your article. Instead of saying Spring is "non-standard", you should say Spring doesn't have a JSR. When you use "non-standard" in a way that violates its basic meaning, you give a false impression of reality. By your use of "non-standard", Struts and Hibernate (and even Shale) would be out of the running when they clearly are "regularly and widely used". Spring is standard as well, though like the others, it doesn't have a JSR.
As for proprietary, consider the nuance that this word holds, "connotations that it is exclusive and cannot be used by other parties without negotiations". Most proprietary APIs by vendors like BEA require "negotiations" in the form of payment, and are therefore not open to use by all. There are no such exclusive restrictions on Spring. In fact, most code that uses Spring for DI can throw Spring out entirely and substitute it for another service that performs creation and relationship management. Spring was intentially written so that your code *did not* rely on it. I've demonstrated this several times to people using real code. So in the sense that proprietary can "lock you into" something, Spring doesn't fit the bill there either. Your code can be wired up with your own home brewed thing or with a competing product. No lock in.
Your use of "non-standard" and "proprietary" isn't a fair representation of Spring. So instead of casting Spring in the "it's evil because it doesn't have a JSR" corner, let the other points of your article stand out to show why you feel EJB 3 is a better solution. You have a valid point of view, and you've got compelling examples. Keeping your nuances straight will help you stay out of the emotional argument and write a more convincing article next time around.
Missing a JSR isn't that big of a deal, I use stuff without JSRs all the time, so your focus there is misapplied. Your points under Service Integration, Flexibility in Service Assembly, and XML Versus Annotation offer the substance of your argument. While I don't share your views, I think all well thought out opinions should be discussed.
Thanks for listening.