See my comment to @Capricorn2481 here[0]. You seem to be saying that unsafe code can be made correct so as to ensure soundness. This can be done by verifying invariants in unsafe code, but it is generally discouraged, as it tempts large unsafe blocks that could be partially safe code. Both you and @Capricorn2481 don't seem to make the distinction between "arbitrary safe code" and "my safe code within the module with unsafe", which is a crucial part of the idea of writing encapsulated unsafe. Technically, I believe unsafe code can still be made sound in the presence of arbitrary safe code, but it would have to tiptoe around violating memory safety, lowering its utility and performance substantially, if not completely.
I accept that criticism. It's just that it makes things more complicated and harder to argue about (and I couldn't remember the exact boundaries). I was making the distinction earlier but dropped it for the sake of explaining the point of safe/unsafe.
So the categories of code: the unsafe block, the friend code that shares responsibility for invariants, the outside world code
Capricorn2481's mistake is putting the entire program in the second category, when only code in the same module is supposed to be there.
If a memory violation happens, you know you have a bug in a module containing unsafe blocks, which helps a lot. Those modules should be relatively rare and as small as possible.
[0] https://news.ycombinator.com/item?id=46057382