I want to understand why the rust community is averse to DI frameworks

I come in peace and I want to hear your opinions and what exactly the rust-y alternative is to dependency injection for large codebases at scale maintained by 100s of people

Plenty of people like to shit on the pattern (i don't want to add links to other posts or comments, but go ahead and search DI in the rust subreddit and see what you find). I find that people cite trait objects are enough, and you shouldn't use magic to create objects - just instantiate with explicit constructors. However, how does that advice help with large codebases of large teams? In my opinion, DI is meant to help with million line codebases maintained by 100s of people:

The limitations - The pattern is cursed, yes I agree. The spring framework sucks in the java ecosystem for a lot of reasons:

1. why would you use it instead of just writing a java constructor and being explicit in your dependencies?
2. you end up having to learn your own codebase as well as spring's codebase to use it for anything other than the happy-path use cases, why would you go through that pain?
3. and the fact that just importing a dependency adds functionality to your code (eg. spring-security just.. adds a full oauth provider to your service, and all sorts of middleware to all your endpoints) why would you allow that?

The benefits - in a million line codebase maintained by 100s of people, DI is less cursed than explicit code:

1. a constructor that needs 10 arguments that each also need 10 arguments, explodes into a 100 lines to make one object (large codebases end up with these.. even if there are better ways to do it, one amateur becomes a senior engineer and everyone creates such constructors in a matter of weeks), so a graph of singletons is just easier to reason about, maintain and constrain developers from doing stupid things
2. learning a DI framework's details instead of the custom code of your own codebase is better because (hopefully) the DI framework has really well designed interfaces and contains best practices, and maintainers and communities that offer you answers when things get really weird. I work for this company whose legacy systems were originally built on explicit code with large constructors, and we moved to spring and well.. work sucks in spring-y ways but at least it doesn't suck in custom company-specific-patterns-implemented-by-fucking-amateur-teams-y ways
3. (ok i don't have a counter for this one, I don't like another team person how my service works, so this is not actually a pro)

So yeah how would one provide the same pros (1) and (2) in a large rust codebase in the rust-iest way possible without a DI framework?

EDIT: I don't know if this is a point of confusion but just to be absolutely absolutely sure DI == dependency injection (not dependency inversion)