Right. However, in many DI-heavy apps I've seen, nobody ever makes use of that flexibility. Otherwise it's just extra, unnecessary complexity, sitting around in verbose XML files and annotations, causing code clutter.
These are "enterprise" Java apps with Spring, etc.
I personally don't see how a couple parameters in the constructor are adding so much complexity that you'd be better off without DI.
A good DI container can make it much easier to follow a pretty good amount of general best practices. Single Responsibility, DRY, and Open-Closed Principle to name a few.
These are "enterprise" Java apps with Spring, etc.