(In this exact situation I do know that there's a quality gate later in the process, and it would be very easy for you to determine that too with at most five minutes of research.)
And again: it was just a way to get the attention of people who might agree with it, to hear their side. Or to start/stimulate a discussion.
I don't like to just believe things because it sounds good and because it has been repeatedly said to be good, without explaining why. The point was to question it, or come up with scenarios where it is not favorable. Do you agree that such scenarios exist where it is not a good thing, or not?
[1] We are still talking about a package manager, and this project specifically.
I think talking about contributions of low effort 'my-hello-world-lib' packages to repositories and contributions to existing codebases have a pretty different dynamic which we shouldn't conflate. For instance, while the npm-cli project is obviously hugely popular as a piece of software, the amount of PRs they get isn't exactly overwhelming, and they seem to accept a high proportion of the ones that do get opened against the project.
Nevertheless, the JavaScript ecosystem is flourishing by all accounts so I'm not that convinced that their repositories being that polluted are as much of a hindrance as some would like to make out. It's just not that much of a problem because people can work with recommendations, popularity, word of mouth or whatever and decide what packages they're willing to accept based on their own organisation's policies rather than having some central authority dictate it to them. You can also argue that a separation of concerns should happen here: Lists of curated packages can exist outside of the repository itself.
I also just don't think it's Cargo's job to put artificial barriers in place. It should be the package maintainer's job to decide what is an appropriate level of difficulty to contribute to them if that's how they see fit to triage contributions. If they want to make it some labyrinthine thing with external dependencies that have to be built by drawing a pentagram in your own time and blood and summoning the elder beast who instructs you as to where to find a binary blob that you have to link against that was lost in the early 1500s then more power to them? But it's not Cargo's job to decide where that line gets drawn.
Look, I came across a neat program written in Rust, and this is how the recommended way to install it looks like: https://streamable.com/iyq6b. The video is truncated, and it took 16 minutes to finish!
This entire "making it easier for everyone to contribute" idea encourages and enables such outcomes. It does sound good, but in practice it is not as good. I understand that it is up to this particular project to avoid dependencies, but that is not what I have seen in ALL pieces of Rust software that I came across. It just seems more prevalent in such ecosystems. Maybe it brings together people who think it is a good idea to depend on 2 lines of code and as many libraries as possible, I don't know.
Remember the days when it was encouraged to have as fewer dependencies as possible? It seems like these days are over because of such ideas.
I think there's a mindset that is imported from agile business culture, more than anything else, that if you're not developing functional requirement business features as fast as humanly possible while meeting the bare minimum for quality then you're being slow and inefficient compared to the guy who's willing to do that. This same mindset also makes it completely unlikely that a tool with any kinds of barriers to entry which would have to be overcome on company time will ever gain any adoption.
The other side of that coin is that where there are community projects which are not supported by companies where developers are just working in their spare time, often around work and so on, to develop something they think might be interesting but cannot commit to making everything the best it could possibly be while also realistically getting the thing done. It also has to work everywhere, it has to look pretty, it can't just work on whatever version of Windows is current and have done with it.
Then there is just a logic to using dependencies because they've already been battle tested for you, there's a decent chance those developers have done a better job than you would given whatever limitations that you have simply because they've put the time and effort into it already. Maybe somebody's even paying them to do it.