If you detect something that can not (well, should not) ever happen, it means that state of the process is no longer within designed bounds.

The process' output can not be trusted, so it should stop processing. Detecting something you never expect to happen is almost tautologically stating the software doesn't know how to recover state.

This, of course, relies on an architecture where another process will take care of making sure an error is bubbled to the place it needs to go, pulling failsafe, etc... I will grant some environments and/or designs make this easier than others (eg. Erlang's error handling is all about letting processes die).

There's a school of thought in security that believes you should hard fail at any attempt to violate an invariant. I believe the linux grsec patches do this. They will just crash the kernel if they see something at runtime that they don't like.

The author writes from the perspective of writing a CGI-based web app. Here, every request becomes a new OS process, so killing the application is killing the request.

If an application is making a request it hasn't marked as being one it is going to make, then chances are, there is a big problem that needs dealt with. In such a situation, crashing as soon as possible means that there's a better chance that all of the relevant data is there to pore through. If you just deny the call, then it could be many hundred of functions later, possibly with relevant data being freed up, and your job of picking through your program's entrails becomes all the more difficult.

Because everyone in dev and ops ignores warnings.

Only stuff that crashes is investigated.

Helps debugging.

Though a sysfs/procfs config for this would go a long way.