You've seen one case where a panic backfired terribly, but you haven't seen the other cases where loud panics helped catch bugs during development, testing, and internal dogfooding/canary releases. Panics (assertions and other "this should never happen" unwinds) can be very useful.
In this case the unwrap() was only a symptom of an already bad state causing an error that the service couldn't recover from. This would have been as much of an unrecoverable error if it was reported in any other way. The mechanisms needed to either prevent it or recover are much more nuanced than just whether it's an unwrap or Result.
Using Result instead isn't universally better. For example:
if let Ok(Some(cached)) = memcache.get() {
this is a reasonable pattern, because communication with the cache server is going to be inherently flaky, and treating it as a cache miss is a trivial way to recover.
…except when you have a cache client that is too old, and doesn't support a certain protocol feature, which makes it systematically fail on a subset of queries. You have no idea, because all users of it discard the Err, and Rust has no good way of enforcing that a certain Error variant must be handled (it boils down to undroppable types).
Mixing of critical "this should never happen" cases with Results that often carry noisy and trivial/expected errors (caused by bad user input, flaky I/O, timeouts, etc.) risks losing the important error in the noise. When a service sees some "missing required http header" trivial error thousands of times per second and a "the core config is all wrong" every 5 minutes, it will be easy to lose the important one in the noise.