Certainly safer, but not memory safe. Operations as simple as multiplying signed integers or popping an empty vec can be undefined behavior which is not memory safe.
Rust tries to solve this by having basic addition panic in debug, while silently-but-consistently continuing in production: overflow is considered a bug, but it is at least not a platform-dependent bug.
If overflow is expected, then there's checked_add to detect it and fail in a friendly way, saturating_add / wrapping_add / carrying_add for specific overflow behavior.
Finally, if speed is crucial and overflow is either impossible or you don't care about the outcome whatsoever, there's unchecked_add to explicitly opt-in to a C-like "just do whatever the machine feels like".
Just like for signed integers in C the {integer}::unchecked_add is Undefined Behaviour if overflow occurs. So that's not "whatever the machine feels like" it's much worse.
This is an unsafe function, so you're expected to write a SAFETY rationale for the unsafe call, and that's your opportunity to justify to a future maintainer why you were sure this addition never overflows. If you find yourself struggling to justify that belief it probably means you should not have used this function.
If you're going to write guard code for overflows, and use that to justify the SAFETY claim, why not use the existing functions for that? Clippy will suggest this in many cases because it's less likely you will blow your own foot off.
At a broad view, we get to a place where there's no "bug" when "what happens on overflow" is what the program(mer) wants.
All I said is that you can remove undefined behavior from signed overflow without having to introduce checks to every arithmetic operation and without having to specify any particular behavior or outcome. The technical term for this is "unspecified behavior" and the consequence of making overflow unspecified behavior is that the consequences of overflow, while still unspecified, must be bounded in space and time, unlike undefined behavior whose consequences are not required to be bounded in either space or time.
You can define a behaviour today that they'll all get, but you can't define a behaviour that matches what each programmer needed when they wrote their operation. Some of them can wrap safely. Some of them would need to saturate. Others would need it to abort.
The problem isn't that the behaviour is undefined per se, it's that you can't tell afterwards which potential behaviour the programmer needs, and choosing one behaviour e.g. wrap will break everyone who actually needed saturating, or trapping, etc.
Contrary to Contracts, which at least managed to get consensus in WG21, I very much doubt that Profiles will get consensus.
Contracts are useful, but don't guaranteed anything if type safety & memory safety can be bypassed.
I think the ISO panel made the right call. The real world consider memory safety & execution integrity to be critical issues, and C++ no longer to be viable. Without some major improvements -- I would consider this view to be correct.