Spring beans, Guice beans? Rally? DI was a hype. Now it's just a joke. Start real programming instead of juggling configuration options to tame your self-produced DI complexity.
I don't agree. Saying "never use DI" is almost so extremist as saying "always use DI". Sometimes it can be useful, sometimes it could be solved bettr with other approach or pattern. Old-style lookup using JNDI is a better strategy?
Maybe he's saying, don't use Spring, et. al. DI works fine in plain Java too.
My biggest problem with Spring based DI is that many times it exposes the guts of your application when a configuration switch works just fine. You don't want users hard coded to implementation details.
I agree with your two points.
Using DI with plain Java with plain Java can be useful too. In fact, we used it years ago in a GWT project (Google GIN wasn't available at that moment). We wrote factories that have the responsibilty of doing the DI.
It is important to keep (where possible) the code decoupled form the container (for example, avoid implementing Spring interfaces), so you can use your classes with Spring, Guice, plain Java DI, etc.
It is correct that using Spring can expose the internals of your system. In order to mitigate the problems that could arise from such issue, we have used property placeholders or JNDI (depending the project) in order to keep separated things that should be changed by programmers from things that should be changed in runtime (by an administrator).