While it may never be “enough” depending on your requirements (which you didn’t specifically and coherently define), the amount of “review”, and having the required know-how to do it competently, is much bigger/higher from your crate dependants, than from your distro packages.

It’s not rare for a distro packager to not know much about the programming language (let a lone the specific code) of some packages they package. It’s very rare for a packager to know much about the specific code of what they package (they may or may not have some level of familiarity with a handful of codebases).

So what you get is someone who pulls source packages (from the interwebs), possibly patching them (and possibly breaking them), compiling them, and giving you the binaries (libs/execs). With source distros, you don’t have the compiling and binary package part. With crates.io, you don’t have the middle man at all. Which is why the comparison was never right from the start. That’s the pondering I left you to do on your own two comments ago.

Almost all sufficiently complex user-space software in your system right now has a lot of dependencies (vendored or packaged), you just don’t think of them because they are not in your face, and/or because you are ambivalent to the realities of how distros work, and what distro developers/packagers actually do (described above). You can see for yourself with whatever the Debian equivalent is to pactree (from pcaman).

At least with cargo, you can have all your dependencies in their source form one command away from you (cargo vendor), so you can trivially inspect as much as you like/require. The only part that adds unknowns/complexities is crates that usebuild.rs. But just like unsafe{}, this factor is actually useful, because it tells you where you should look first with the biggest magnifying glass. And just like cargo itself, the streamlining of the process means there aren’t thousands of ways/places in the build process to do something.