Sometimes you have to satisfy the compiler because it has less information about a situation than you do. Ideally this would be captured in the type system, but limitations (language, project, politics, time, etc) may prevent this. As another comment mentions, it's a kind of invariant check.
For example, based on external information you might know[1] that a condition inside of a loop will always be hit exactly one time. Your compiler or tools might not be able to determine that same thing. It may try to force you to do something like assign a value or whatever you did in that condition, that it can't guarantee has happened. In such a scenario, it might[2] make sense to have something like "this should never happen" after the loop, with a brief comment explaining why you've done this.
[1] I think this is the crux of the issue. We programmers often think we "know" something, but it might be an incorrect assumption. IMO part of being a good programmer is examining your assumptions at every step. The chasm is vast, between "the framework strongly guarantees X" and "the function that gets called before this one has done X already". The former is OK if you want to get work done, while the latter is much more brittle and possibly dangerous, depending on the level of coupling you're willing to accept.
[2] Nine times out of ten, a reorganization of the logic makes more sense. However, I do think there are scenarios where this pattern is the best choice given the options.