I had an argument about DI with a friend months ago and it boiled down in his use (Guice) that it was only for testing components.
I think of DI as a big meta-constructor in the sky, it gives dynamic scope to a lexically scoped language. And the problem with it as we currently use it, is that it hides intent behind a config file so we can't read what the code is actually doing, only doing abstractly.
What if the tooling ghosted those abstract classes and put the concrete classes in their place with reading and navigating? It could effectively "statically link" in the IDE those dependencies.
As I already said, you always need to wire your objects. You do it, possibly, without realizing it, but you still do it. If you reject the idea of DI just because the code is bad and DI is "Not Invented Here", you will not do the wiring better. Writting custom DI is hard, and it's very likely that you will end with unmaintainable nightmare that needs to be rewritten completely. For 15 years I've seen this nightmare too much and never seen the successful projects with custom DI.
The task of dependency injection appears right after the decomposition of a problem: you cannot avoid it, so you either do it manually by constructing and wiring all necessary objects (self-managed singleton anti-pattern is quite common here, let his fathers burn in hell) or using a DI container. Unless you want to invent your own bicycle with poker and curvy girls (which may make sense in very specific cases, but not in general), you will use Spring, Guice or CDI.
How to choose the right solution? It always depends on requirements, not on generic concepts from theory of OOD. In small project you can follow KISS principle by sacrificing decoupling and wiring objects manually. In bigger one you always need to look at the other libraries and environment you are going to use. If it's a JEE container (a modern one, compatible with latest specs), your choice can be CDI. If you are going to work with GWT, it's Guice (it's the best for programmatic configuration, but lacks some features). In all other cases Spring 4 is the best option.
What's wrong with the talk about reuse vs decoupling? The author addresses the problem of sustainability of a system to changes by rejecting the core concept of OOD - the reuse - and avoiding the use of DI, just to avoid some hypothetic bug in implementation module. However, our industry developed a lot of tools and best practices to address such problems when writing reusable code: unit tests, SOLID (SRP is my favorite one), incremental compilers and smart IDEs. Avoiding reuse is like not using electricity if you afraid of fire.