Quite. Not only is this useful for logic errors, it's useful for runtime error paths that are almost impossible to test and that it is nearly impossible to continue execution past.
The classic example of this is OOM. I would divide this into two subsets: if you're writing a library routine whose primary purpose is memory allocation and that can be expected to allocate a lot (e.g. a data structure's initialization function), and it runs out of memory, then by all means free what you allocated and return NULL. But if you're writing a library routine whose primary purpose is something else, and recovery from OOM is going to be tricky, then just exit() (and document this policy, of course). Your caller is unlikely to be able to do anything much on OOM anyway, exiting will free up memory at once, and if your caller is desperate to clean up or even jump out and keep going after freeing up memory, that's what atexit() is for.
But, be honest, your caller isn't going to jump away and keep going on OOM, your caller will just die: anything else is too hard to test properly. If you're lucky your caller might arrange to clean up in atexit() handlers, though I note the X server never does this and just appears to *hope* that none of its libraries exit on OOM. But perhaps this is because you can't even rely on cleaning up in atexit() handlers, because if you happen to OOM in a stack allocation the kernel is just going to kill you. So it doesn't matter if you have lots of complex cleanup-and-continue OOM code, you have to cater for an immediate exit without cleanup *anyway*. And you can't avoid this merely by not using malloc(): you have to not call functions either, at least not without 'preallocating' stack space by doing a deep recursion in advance. A few programs actually do this, but it's rare.)
There is one thing I wish we could get, but is really hard to do properly -- an automatic backtrace on OOM, so we could tell roughly which allocation was failing and why. Unfortunately on most platforms that requires a modicum of debugging information for everything, and that's huge and not loaded by default, even if it's present, so you'd be unlikely to be able to consult it at OOM time anyway.)