I agree, "people want to write code that runs and thats it" but there's a subset of folks who like to write their code in C/C++ and crank up the warnings, turn on ASan/UBSan, valgrind+electric fence, etc.
To be successful, Rust doesn't have to obsolete C and C++. It just has to attract a critical group of the next generation of systems programmers.
Rust has very little competition in this space (newly designed languages that can be used to write ISRs, bootloaders, OS kernels, etc). Many of the other popular languages strive to find some middle ground between C/C++ and Java/C#/Python.
At the end of the day, many of us are paid to ship features. For many industries, correctness and safety just can't compete with new features. It's the reason Lisp, Python, Ruby, and Go are so popular - you can quickly write programs which are both fast enough and memory safe.
The gaming industry, one of the bigger C++ consumers, will also probably not move to Rust for similar reasons: hitting a schedule is much more important than not crashing or not having memory leaks. You can always patch a game.
Not all errors, only a particular class of memory errors. Most of those memory errors are those that a GCed language doesn't have to worry about, and C/C++ have a bevy of tools to find those errors before they leave the developer's hands as well.
That said, Rust's borrow checker will also help protect against a class of shared memory mutation errors as well. Is the time cost of pleasing the borrow checker for every memory allocation worth this benefit? Probably something only individual developers can answer. My answer is, for now, no.