[V-2]

For simple scenarios DI is obviously an overkill, but as soon as you're dealing with nested dependencies, you'd end up with either:

* monstrously big constructors (for carrying transitive dependencies)

* lots of @VisibleForTesting code to handle manually injecting various dependencies only for the sake of testing (poor man's DI and generally bad practice)

* a lot of factories (service locator or poor man's DI, essentially)

* code that's hard to unit test due to dependencies being hardcoded.

In other words, you'll either reinvent DI poorly, or give up on testability.