You raised an issue that the other bulletpoint has the solution for, I really don't see how these are "key differences".

In Rust there always only one owner while in C++ you can leak ownership if you are using shared_ptr.

That's what unique_ptr would be for. If you don't want to leak ownership, unique pointer is exactly what you are looking for.

In Rust you can borrow references you do not own safely and in C++ there is no gurantee a unique_ptr can be shared safely.

Well yeah, because that's what shared_ptr is for. If you need to borrow references, then it's a shared lifetime. If the code doesn't participate in lifetime, then ofcourse you can pass a reference safely even to whatever a unique_ptr points to.

The last bulletpoint, sure that's a key difference, but it's partially incorrect. I deal with performance (as well as write Rust code professionally), this set of optimizations isn't so impactful in an average large codebase. There's no magical optimization that can be done to improve how fast objects get destroyed, but what you can optimize is aliasing issues, which languages like C++ and C have issues with (which is why vendor specific keywords like __restrict exists). This can have profound impact in very small segments of your codebase, though the average programmer is rarely ever going to run into that case.