I give Google a lot of well-deserved criticism, but they handled this issue pretty well and quite promptly.
The other thing of course, is that the domain was expiring. So similar to PyPI just accepting in the parent article that an expired domain isn't trustworthy, Google could verify shortly thereafter whether or not the domain was renewed by the developer in question.
And ultimately, you're suggesting paying off an official to pretend someone is dead, so you can block package updates to a domain, which doesn't really introduce a security issue, and of course, is trivially reversible when the person in question is, in fact, still alive. As Tony Stark would say, "Not a good plan".
I forever am and forever will be a civil engineer somewhere in upstate New York thanks to them. Nevermind I was still in high school at the time and don't even have a shred of engineering qualifications. Whoever you are, thanks for the borrowed ladder my friend.
Upstreams going dark happens much more often than them going rogue. A system that requires you to prove more than you just control a domain isn't as vulnerable to this problem.
Say I'm using mydomain.org/abc and it's a perfectly fine package. I'm currently using v1.25.7. Two months later, I see a new version of mydomain.org/abc, v1.25.8. I will likely update to it and use it relatively confidently. But, unbeknownst to me, mydomain.org's registration expired one month ago, and a malicious actor has grabbed it in the meantime; and they have now released a malicious version of this package. Nothing in Go's security model prevents this type of attack, except that Google's package "cache" (the package repo that Go downloads things from) can be configured by Google to not provide that malicious package.
This is a major design flaw with the silly idea of using an extremely imparmenent identifier - DNS names, which can only be leased for a limited time and are automatically auctioned off after they expire - as the main identifier for something as long lived as Go packages. No other package ecosystem has this terrible design concept - even when they do use DNS, they use it only for an initial authentication, not as the only identifier.
For example, in Java's Maven repo, to publish a package org.mydomain.abc from a Maven Central account, you need to prove that you have ownership of abc.mydomain.org once when associating this package. Afterwards, the package name remains associated with your Maven Central account, forever. If you lose access to that domain name and someone else obtains, they can't go through the same steps, Maven Central won't let them, since that package name is already tied to your account.
However, when devs change dependencies, an innocent `go mod …` might update to a new (compromised) version of a dependency.