In the cold light of day I agree, but we're not robots; discussions have an emotional aspect to them and sometimes an emotional response needs to be expressed. You can't be that person who tells everyone "you're doing it wrong" unless you really know for sure they are, and even then you shouldn't make them feel bad about it.
It's worse when the subject is a nascent project and people's ideas are forming out of discussions like this, but in general it has a chilling effect on the subject being discussed. In this particular example, we need to know the deficiencies of Rust's allocation model, and there is much to be gained by discussing them and finding a workable solution. Shutting down the discussion with 'use the safety tools you already have or you're a foolish brogrammer' is not acceptable.
Rust is a new language. Its designers are close to solving the problems they set out to solve, but they haven't fully succeeded yet. Heavy use of "unsafe" indicates that there are things you can't properly express in the language, or can only express inefficiently.
It's worthwhile to separate the two. If you can't do it at all, there's a problem with expressiveness. If you can't do it fast, there's a problem with performance. It's useful to try to do things without using "unsafe" to cheat the system. Then you find out what the language needs to do faster. That's a trouble spot to be identified. There may be an optimization which leads to a safe and fast solution. Or there may be a way to make something checkable so that it's not necessary to do something unsafe.
