Guess it’s the same difference between caught exceptions and panics, you can either recover or you cannot?
Disk errors happening after a deferred write are a classic example that's still applicable today. Your process might have succeeded a write(2) into cache and exited cleanly, then when it's time to write to disk, something bad happens. There's no way to tell an application that is long gone.
I'm illustrating a real world scenario where such a mapping may not be possible.
Further, if the issue is a global problem, like filesystem corruption, it becomes even more ambiguous -- maybe that write could have worked or maybe it wouldn't, but the filesystem may just globally make everything read only and start failing writes.
So my point is that these errors were meant for catastrophic failures that don't map neatly into being handled with the process. In a modern kernel there are way fewer of these conditions than was acceptable in the early 90s. But there are a few similar things that are still common.