Rust would have prevented about half of the CVEs in C code (I've seen a few different studies with somewhat different results, half is close enough for discussion). The other half is on you to write good code.
Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.
There is a time when you need unsafe. Hopefully those are rare, but most rust projects will need it. (remember Rust is aiming for systems programming, some domains never need unsafe, but others will need it).
I'm a c++ guy interested in Rust, my understanding is Unsafe lets me design custom high performance interfaces that do weird pointer tricks (which is needed to interface to the C and C++98 interfaces I work with), and it is on me to bounds check. Then the users of my interface don't use unsafe because I did all the nasty parts and their code is easy to write well.
If you mean "writing unsafe in your codebase yourself," this isn't borne out by the numbers.
If you mean "depending on unsafe somewhere in your dependencies" then 100% of Rust code needs unsafe, just like any other language. Interacting with hardware, many operating systems' APIs, these aren't created in a way to guarantee it, and you need to interact with them to do anything.
I'm biased here because I work in embedded where I can't see any way to write code that directly interacts with hardware without unsafe. There are other world out there that I don't know much about.
Unsafe is necessary for Rust to meet its goal of being a systems language. If Rust didn't provide unsafe, then Rust programmers would be forced write this code in C, which would be just as unsafe, but a worse developer experience.
Note that the half Rust would prevent tends to be less impactful, still a CVE, but the exploit is less impactful to end users.