Only three rust benchmarks use unsafe code, in one of them it's virtually mandatory, and in another it's just one line. On a side note, rust compiler enforces naming conventions, which is kind of cute.
The reverse complement program certainly doesn't need unsafe code, but the safe rust version[1] takes 3x the execution time of the unsafe rust version[2]. By comparison the fastest Go version[3] is fairly idiomatic Go without unsafe memory management and takes just 2x the time of the unsafe rust version.
Also, which benchmark did you have in mind when you said unsafe code is mandatory?
These are REALLY BAD examples, the safe rust version isn't parallelized but the two others are. The unsafe version is just translated C as people already stated. A safe version these days (heading towards 1.0) shouldn't be far of the unsafe versions.
That specific safe version, which, IIRC, was a basic translation of the fastest C version. I'd guess that there's other safe variations that are more idiomatic and much faster.
May be a faster safe version should be contributed. The current state is that unsafe rust takes half as much time as a safe go program in this benchmark. That is not very interesting because the benefits offered by rust are being given up to perform better, for a problem that doesn't really need unsafe memory access.
Same is the case with spectral norm. It is unsafe rust beating safe go there too.
Small, widely-verified blocks of unsafe code should be the norm if unsafe code is necessary. This does not mean "if you're using unsafe you've failed!"