Assurance there are can be no panics has practical benefits, beyond the "but what about bugs?" question. Exception safety is a complication for unsafe code, and has been a source unsoundness in Rust (to the point there's an RFC proposing to remove ability to unwind from Drop entirely). It has performance costs (code bloat, inhibits code motion and autovectorization).
No-panic as an assertion has a value of ensuring that your expectations match. You can ensure that an infallible function really is infallible. You can ensure that a function that returns Result fails only this way. You can ensure your code running in non-Rust stack frames doesn't need a double catch_unwind sandwich.
Even when the code correctly uses panics for what it considers bugs, maybe the code's contract needs to be changed. For example you can have a function that requires a convex polygon as an input. If you pass it a non-convex polygon, it's clearly your bug. But if you get points from an untrusted source, adding an `is_convex` check may be insufficient, because due to rounding errors your check and function's check may disagree and you get a DoS vector, and you pay cost of checking twice. If you need it in real-time graphics, a non-panicking garbage-in garbage-out approach may be better.
That all sounds fine and good. Of course assurance that there are no panics has practical benefits. Sign me up.
I'm still not sure what that has to do with complaining that Rust makes it too easy to panic. What's the alternative? If you're suggesting "garbage-in-garbage-out" everywhere, then I don't think that's a plausible answer for things like 'slice[i]' or 'RefCell::borrow()'. Whether garbage-in-garbage-out makes sense as a strategy depends a lot of the specifics of the situation. (And your polygon example sounds like one of those.) But that to me doesn't suggest something systemically wrong with the frequency of panicking branches in Rust code.
The alternative is to have control, so you can choose (and enforce) the right strategy for your context: unwinding, or aborting, or only infallible/Result/GIGO (with turning `slice[i]` and `RefCell::borrow()` into compile-time errors where necessary). Rust's default of "anything can unwind anywhere at any time time" is just one of these strategies, and it's not always the right one. And when it's not the right one, it does create a "mine field" as the OP says.
I think I see what you're saying now. I guess time will tell, but I don't think the alternative you pose will get rid of the so-called "mine field." So I still stand by what I said: complaining about too many panics is like complaining about too many bugs. I think a different complaint, i.e., "Rust doesn't give enough visibility and control with respect to panics," is a different story entirely and is valid. (Although I don't particularly suffer from its absence.) With that said, it would be cool to have the level of control you're talking about, but it's not clear to me the extra language complexity required for it is worth it. But hard to say at just a conceptual level.
No-panic as an assertion has a value of ensuring that your expectations match. You can ensure that an infallible function really is infallible. You can ensure that a function that returns Result fails only this way. You can ensure your code running in non-Rust stack frames doesn't need a double catch_unwind sandwich.
Even when the code correctly uses panics for what it considers bugs, maybe the code's contract needs to be changed. For example you can have a function that requires a convex polygon as an input. If you pass it a non-convex polygon, it's clearly your bug. But if you get points from an untrusted source, adding an `is_convex` check may be insufficient, because due to rounding errors your check and function's check may disagree and you get a DoS vector, and you pay cost of checking twice. If you need it in real-time graphics, a non-panicking garbage-in garbage-out approach may be better.