It was mostly programmed in object-oriented Pascal. One of the first big uses of an OO language. And it was terribly big and slow, requiring a fatally expensive amount of RAM at the time. A lot of those abstractions were stripped out for Macintosh in a bid to slim things down extensively, and they have not really been tried elsewhere since.
Isn't this largely the same in the modern desktop? File explorers do call handlers for each files. But it's also true that the recent trends among apps half-killed the concept of file explorer - they use built-in search functions these days. It's good in its own ways, but often it's necessary to go through filesystem when working with multiple apps, which can be awkward in terms of data management.
Also, many apps automatically save states on close. A problem is that the behavior is far from being standardized, and there are tons of different ways how apps handle their states. This usually gets really painful, as one must learn each app through trial-and-error.
If you invent a new disc controller, for example, you can change the vector for Interrupt 0x19 to point to your code, and if you realize from the body of the request that the call was intended for another device, you pass it on to the original code.
There were two problems:
* The standard BIOS features were somewhat limited and narrow. * They added enough overhead that you might want to ignore them and start fiddling with registers directly.
This was especially true for video control (BIOS Interrupt 0x10). Nobody was going to follow through on the proper way of stuffing the framebuffer when it was memory mapped and you could just dump stuff straight into it. So on the one hand, it meant a BIOS-level compatibility wasn't enough, and it also forced hardware rictus (I could imagine, for example, a video standard which communicated with I/O ports to open up more addressable memory, but there's no way it would support anything but the most well-behaved software).