Maven Central uses verified reversed domain names, so to own `com.google` you need to prove you own the domain `google.com`. It's not hard to do it.
Dart's pub does the same thing with verified publishers.
crates.io already requires user accounts from publishers, so it already manages identity.
The only reason they don't require namespaces is to make crate names look cooler and the barrier to entry non-existen, so they can amass large numbers of packages in a short time (then deal with the fallout only when it becomes an emergency), I can't see any other reason anywhere, including from the ones you've raised.
It currently requires a Github account, but the registry is not tightly coupled to Github. But once you introduce Github identities as something that code is explicitly depending on, now you're at the mercy of Github for the rest of time. Furthermore, immutability is a desirable property of package registries, and Github identities are not immutable; Github allows people to change their usernames and then allows any random person to snap up the old username.
> The only reason they don't require namespaces is to make crate names look cooler and the barrier to entry non-existen, so they can amass large numbers of packages in a short time
No, this is needlessly conspiratorial. Please exercise some perspective. crates.io is run by volunteers, and managing an immutable identity layer is not something that the current crop of volunteers wants to commit to.
When a domain changes hands, it's also up to users to decide whether to trust the new owner's TLS certificate... I am saying this because this is forms the basics of Internet security, when people bring this argument up, they show a certain ignorance of how things work on the Internet in general.
You can, of course, have both, if you use DNSSEC and DNS “PGP” records; the PGP key is then validated by the DNS.
Again, Internet security is mostly based on trust and there's no way around that: when you enter a URL on a browser, you need to trust that the domain belongs to who you think it belongs, and the only way you have to do that is to trust its TLS certificate... which you do by explicitly trusting your browser to only recognize reliable TLS certificates signed by a legit root certificate authority... unless you decide to whitelist TLS certificates yourself by obtaining the domain's root certificates out-of-band, something nobody seems to think necessary to do, even the most security-conscious government agencies probably go to that kidn of trouble.
Basing package ownership on the same kind of mechanism is the best you can ever do... if you consider that as not being a good enough solution, then you should never use the internet with consumer-grade browsers at all, let alone use package managers in any form.
The fact that we all use and trust CA-issued certificates today is not an argument for accepting that system as the best we could ever do in the future, or even today. And the fact that one wishes to improve the current situation does not make it wrong to use the current system as it is – to claim otherwise is to be Mister Gotcha (https://thenib.com/mister-gotcha/).
Identity layers are hard. It's a problem worth solving, but it's not going to happen on a volunteer basis. It needs full-time paid employees to deal with this. Perhaps the Rust Foundation will make such a thing a priority.