I notice that rustls for example does not implement DES. So, while a Go program that wants to do DES TLS should get flagged by this tool, a Rust program that wants do DES TLS has to go find a less popular TLS library, which ought to serve as a reminder that this is a bad idea.
Of course the flip side of this coin is that sure enough there's a Rust crate that just implements DES. If you really want to do DES even in Go this lint tool can't prevent you from renaming it BobsNiceCipher and using it anyway... at some level you need engineering teams who'll say "No".
The problem with software engineering is there are a thousand ways you can accidentally do something wrong when writing and deploying software in a secure environment.
Is it a coincidence? Nope, sure enough Go's "unsafe" is closely related to the unsafe concept in Rust, it allows you to defeat type safety promises in Go. Go's promises are much weaker than Rust's but it surely does make sense to audit the use of these features and the same goes for Rust's "unsafe" keyword.
OK. But the other 29 aren't related right? Not so fast. "G601: Implicit memory aliasing of items from a range statement" is in fact about memory aliasing. You can't introduce such aliases in Rust... from safe code. But your unsafe code can introduce an alias that shouldn't exist and thereby introduce incorrect behaviour.
Now, the Go lint for G601 has a lot of false positives. Practical experience tells us that this causes two problems, and in many cases they get out of control. One is, some people begin causing false positives without knowing it, their code is fine but is always flagged by this check, making it a nuisance. The second is, because it's a nuisance, it becomes trivial for developers to ignore it. "Just another false positive" and so it ceases to have practical value.
There are a whole bunch of things here that are orthogonal to "grep for unsafe" and should be in a security-focused linter for Rust, but in fact two of these thirty rules are just "grep for unsafe" in Rust.