The difference is, you put up a sign “here be dragons” with unsafe. Certain operations break the garanties of rust, like pointer operations and Cells. So now you need to write a wrapper which upholds checks that they are not violated. If it breaks, you just need to check your unsafe code, instead of everything. Now only one person needs to deal with unsafe for everyone in a team to benefit.
Memory safety isn’t a skill issue. There is a reason they happen in all big projects like android or chrome and only reduced when introducing safe languages.
I’d rather have a compiler that tells me why my code was refused than a compiler which prints 100 lines of templates. Or a compiler, which tells me a pointer/reference is null instead of a compiler that knows, but it’s UB-NDR so it isn’t snitching. If the compiler tells me, hey here you could have a race condition, it’s one less bug I have to find with a debugger. A compiler that complains about uninitiated variables, instead of a compiler that gives me potluck as content.
Yes, writing safe code is a skill. But for most skills you need someone to teach you. My suggestion is, think about it differently:
The compiler isn’t training wheels, but rather a senior dev, that quickly looks over your shoulder and tells you, hey you might have missed something here. You can at any point tell them, trust me bro for this part. They need at some points a comment in the form of lifetime annotations. They are pretty good, but not perfect.
To pick up your example. They don’t tell you, you need a new wheel. They tell you, you’re bike has disc brakes, but your new wheel is missing the disk. When you later hit a wall, because you couldn’t break, you can check where you just said trust me.