I don't think those are the only two scenarios. I think the most likely scenario by far is user input triggering a latent issue in a code path and promptly bringing the application down. A classic example, of course, is a missing bounds check.
Modern language design makes this less likely by enforcing invariants, adding checks, and making these kinds of issues impossible by construction. It doesn't mean that there isn't a space for languages without these safe guards, but it does mean you should have a really good reason to use them.
> But bugs are bugs, if I'm called at 3am to fix a bug, I don't want to spend hours trying to fight my compiler, and then fall back asleep while I'm waiting for it to compile. I want to quickly identify the issue, and then to be able to write the smallest possible patch until morning. In my limited experience, rust is conducive to neither of those options.
In my experience with Rust specifically, I've actually found it easier to make those kinds of fixes as the area of code I have to reason about is much smaller. I don't have to worry that a local change will have global effects, as I can much more clearly see the dataflow. It's not a silver bullet, but I've felt much more comfortable doing emergency fixes on Rust than on C++.