There's plenty of situations where telling developers to go change their code so it doesn't panic might be an appropriate lint. Think safety critical rust for example.
A lot of panics are placed instead of proper error handling as a cause of happy-path programming. (E.g. all cases of .unwrap())
Some panics are placed not knowing they’re panics. (E.g. indexing, calling a function that panics)
Some panics are legitimately placed by people who want a program to panic at a given place; this may collide with the caller’s desire to use Result and error types.
There are lots of situations where being notified about where the panics live can make your code more robust, because they do sneak in.
https://doc.rust-lang.org/std/macro.unreachable.html
In those cases you strike a deal with the devil. The type system won't help you.
Maybe it's an acceptable tradeoff for readability and efficiency.
Maybe you could have modelled the code so it wasn't necessary.
I think you can divide the use of `unreachable!()` in two cases:
1) As a consequence of style (applying LEM to code)
2) As a consequence of low-level abstractions
And I am also not arguing for the use of `unreachable_unchecked!()`.
I am only arguing that in all the other cases mentioned, you can simply avoid panics.
I'm not saying that lint should be enabled by default. It's a highly specialized config, but it's an important protection when it's useful.