Code without any DI runs the well-known risk of getting tangled up into Spaghetti code - some symptoms are that the classes and methods are too large, do too much and cannot be easy changed, broken down, refactored, or tested.
Code with DI used a lot can be Ravioli code where each small class is like an individual ravioli nugget - it does one small thing and the single responsibility principle is adhered to, which is good. But looking at classes on their own it's hard to see what the system as a whole does, since this depends on how all these many small parts fit together, which is hard to see. It just looks like a big pile of small things.
By avoiding the spaghetti complexity of big bits of coupled code within a large class, you run the risk of another kind of complexity, where there are lots of simple little classes and the interactions between them are complex.
I don't think that this is a fatal downside - DI is still very much worthwhile. Some degree of ravioli style with small classes that do just one thing is probably good. Even in excess, I don't think that it is bad as spaghetti code. But being aware that it can be taken too far is the first step to avoiding it. Follow the links for discussion of how to avoid it.
