I suppose the makers of Nim named that flag for a reason - giving up memory safety by disabling bounds/overflow checks should be never be the default for networked software in a production setting, so benchmarking in that mode would paint an unrealistic picture.
What you want are comparable compiler flags across languages, say "optimized for performance, yet retaining safety" and "go as fast as possible and disable all brakes". Which, to be fair, is the default for C anyway, but this is not a desirable default. I'm sure you can similarly game Rust bechmarks by using "unsafe".
Rust doesn’t have a compiler flag for this, instead it has separate functions that don’t do the checking. E.g. Vec has a .get_unchecked function.
Such functions can only be used in an unsafe block, and should only be used if bounds checking is handled elsewhere such that it would be impossible to cause an out of bounds error at runtime.
It’s also often possible to get rust to elide bounds checks by using iterators, which often don’t need them as they know the length up front.
If you're going into production with Nim code and execution speed is a top concern, you're probably going to remove all the safety belts after thoroughly testing, valgrind'ing, etc., i.e. you're probably going to opt for -d:danger instead of -d:release. But maybe not, depends on the project I guess.
The word "danger" is scary, but it's simply disabling debugging code: debug assertions, full stacktraces, extra safety checks.