I think part of the issue is that it's just so easy to get a package included in "the" central registry, and for many programming adepts that's like a badge of honor. So you get many tiny libraries, and many turn into balls of mud. Then they learn about reuse and happily pull in all dependencies they can think of.
In Rust there seems to be a tendency to keep stuff out of the standard library, so everyone depends on their favorite solutions to everyday problems, which depends on their favorites and so on.
But it is a problem, because somewhere along the line one of those indirect dependencies is going to start conflicting with something else in the graph; the bigger the graph, the more conflicts.
And finally risk, because if a major indirect dependency goes belly up, that may well cause serious problems for your direct dependencies, which then makes it your problem. Also directly related to graph size.
Rust is statically compiled, so it’s possible to have different versions of the same dependency in your dependency graph without build issues. Yes, that can lead to binary bloat and slower build times and some related problems, but in practice the compiler is good at dealing with those issues.
I agree that having a great number of sources needed to build your program is worrying from the point of supply chain attack, but at the same time most developers enjoy focusing on the core problem they are solving, not problems that others have already solved for them.
Vendoring dependencies might be a partial solution, though practically speaking it seems locking dependencies via git hashes would be effectively the same.