There's an engineering tradeoff underlying this, and the balance point on that tradeoff varies over time. Rust isn't particularly good at correctness of programs compared to something like Agda, but it is much easier to write Rust programs than Agda programs.
The sides of the tradeoff are problem domain complexity, runtime cost, programmer effort, and compile-time cost. Sensible engineers recognise that the right balance between those sides varies over time. Ada in part failed because the compile-time cost of Ada code was high compared to C code, and at the time, it was cheaper to put more programmer effort into C code than to put more compile-time effort into Ada code.
For example, in 1988, I was using a computer that, adjusted for inflation, would cost $3,400 in today's money (not including monitor); that set my compile-time cost budget as allowing for what I could reasonably do on a single core 8 MHz ARM2 CPU with 1 MiB RAM. Today, a comparable spend comfortably gets me 16 cores at 3 GHz, and 64 GiB RAM. That, in turn, means that I can afford considerably more compile-time cost for the same productivity, because the compute resources at compile time are much higher than they were 35 years ago. Similar applies to runtime costs; you can get a 200 MHz 32-bit ARM core with hundreds of kilobytes of embedded RAM for less than I used to pay for a 4 MHz Z80 and 256 bytes of RAM; I can thus afford much higher runtime cost.
Countering that, programmer effort hasn't become cheaper, and problem domain complexity has risen - we expect to do more with our systems than we could do in the early 1990s, and we don't have an army of cheap programmers who can implement anything you ask for quickly.
As a result, the optimum tradeoff has moved - we want less programmer effort, since that's still expensive, but we can afford to spend a lot more at compile-time to make that happen. We can also afford a little more at runtime, but not as much as we can afford compile-time cost, because runtime cost is also being consumed by problem domain complexity.
And this shift has been happening continuously over the existence of computing - when you learnt on a batch programming mainframe, the cost of a runtime crash was high, because you'd obliterate not just your own work, but also many other people's work. When the cost of runtime crashes fell (because you had a machine to yourself), it was cheaper to let the machine crash and reduce programmer effort than it was to maintain the high-effort, high-correctness world. And now the compile-time cost is falling, too, so it's cheaper to reduce programmer effort by having more checks done by the compiler.