DOS itself literally took up an entire disk. You'd have a DOS disk with the DOS utilities like fdisk.exe and format.exe, but you'd boot off that, then swap to a program disk to do actual stuff.
One early DOS IDE (Turbo Pascal 2 or 3 I think?) would prompt you to load error messages off disk at startup. If you chose not to, it would free up some memory for your project and you'd need to look up the messages in the manual by error number.
Only a few years later, every PC had a hard drive, >1MB storage on a floppy, and the full 1MB real mode address space filled with RAM.
With software, it's probably a matter of prioritization, why invest into explaining errors when you can work on preventing them? Not that this error prevention always works out, but still.
Of course, nowadays, the "intercept anything, do with it whatever you like" mindset is, at best, a security nightmare, and in any case an adware vector. "Hey, you just had an read error on your Seagate device... Don't you know Micropolis does a lot better?"
So, rightfully so. But I still miss those days...
Abort: kill the requesting process. Retry: jump back to the entry point. Ignore: return as if the request was OK.
Later DOS versions added the "Fail" option, which was like "Ignore", but returned an actual error code. But since most applications were not aware of that, "Fail" was pretty much equivalent to "Ignore" for a long time.
A common third-party TSR at the time was PC Magazine's SAFARI: "Stay Away From Abort, Retry, Ignore". It would retry a few times, then ignore and/or fail depending on OS capabilities.
"Abort, Retry, Ignore (and/or Fail)" was pretty much the "BSOD" of the DOS generation: misunderstood, yet useful for those who understood its code.