Why? Personal preference I guess? Constructor injection works fine for low level objects that only take 1 or 2 dependencies, but for higher level business objects that might have a wider dependency reach, constructor injection can become a nightmare.
I've answered the problem with setter based DI elsewhere in these comments, but another way to say it is because you've now made the behavior of the system, not just the data, mutable state. Which is harder to reason about, harder to test, and harder to get right in concurrent contexts.
> for higher level business objects that might have a wider dependency reach, constructor injection can become a nightmare.
Again, I view this as a symptom of bad design. If you have a wide dependency reach, then using a DI container is only allowing you to increase the problem. Using setter DI, which normally compromises the design even more, to supposedly make the design better is suspect.
I think you would be better served by fixing your high level business objects to not have a wider dependency reach, and the dependency inversion principle is one tool with which you can do that.
What I did intend to say is that having a wide dependency reach is a negative outcome, that is usually the result of bad design choices. That high level components have many low level dependencies is precise evidence that the dependency inversion principle has not been followed.
The entire point of the principle is to decouple high level components from low level ones and to flatten that hierarchy so that the components become peers that each own their own abstractions around dependencies.
Not using setter injection eliminates a huge class of bugs that occur when people try to use objects that haven't had all of their dependencies injected yet:
$user = new RegisteredUser();
// Any code that touches $user here will be bad
$user->setEmail($email);
Which is why people use library to do it for them - an example for PHP https://github.com/rdlowrey/auryn.