It had terminal capabilities (not to the level of termcap in Unix, but good) which meant that shrinkwrapped software like Wordstar would run on anything with an 8080, Z80, or NEC V20/V30 and CP/M. The Osborne 1's tiny screen was only 50 characters wide instead of 80, but software still ran on it.
It hit the sweet spot of abstraction for its time, and made it easy to write drivers for custom hardware that a new manufacturer might decide to make.
I dunno what CP/M you were using, but all the rest of us had application specific patches for Wordstar for whatever we were running, and pretty much everything else. The Wordstar branded for Osborne did not work right on a Cromenco+VT100 and definitely went weird on a TRS-80 4P without directly patching it. Don't even get me started on the cornucopia of floppy disk formats one had to deal with.
Not sure what the VT100 link was supposed to prove other than yeah terminals back then were hard to support generically. And you had to hack around the issues. Which was my point.
The "Osborne-specific version" was the retail version...for the Osborne. Yeah, there was a 'generic' retail Wordstar...that you had to patch for your specific hardware if your combo wasn't supported out of the box. I had friends who's whole business back then was hacking popular CP/M apps to support less popular hardware.
There wasn't some compatibility nirvana. It was just easy to hack up a fix because apps were on the order of 10's or 100's of kilobytes, not hundreds of megabytes.
One reason is that unlike MS-DOS, the OS is hardware independent, except that an 8080-compatible CPU was needed (8080, z80, some NEC chips etc). Other than that you could use just about anything. It wasn't hard to port (more like transport than port) CP/M to a new system which met the minimum requirements (cpu, some minimum amount of RAM, floppy disks at least, and a TTY or terminal). Very different from MS-DOS, which required a mostly exact PC clone, and it had no provision for moving to another architecture. CP/M came with, among other tools, "MOVECPM", a program to relocate the operating system to a different place in the memory map (and write the result to a new boot floppy or whatever), an Alteration Guide document, and there were various books detailing the process.
CP/M didn't require a floppy. You could boot it off ROMs, tape or even paper tape (ASR-33s were fun). There's even a RDR: device that was supposed to be used to load from a card reader, tho I confess I never saw that in the wild.
MS-DOS was structured the same as CP/M: there was a small-ish machine dependent part you ported (called an 'OEM Adaption Kit' at one time), and a hardware independent kernel. At least through 3.0 and probably later, it did not require a PC clone. It ran on all sorts of non-PC 8088/8086 machines. Ever run MS-DOS on an 80186 with 8" floppies? I have. Now, your apps might not run because of machine level assumptions (video, usually), but MS-DOS did.
I still have a British-made 8086 almost-PC in the attic. It ran MS-DOS - but harddisks didn't work because the interrupt vector was different. That could be fixed - I burned a new EPROM and got it working. The company which imported the machine told me how - I called them and the guy who took the call explained in detail about interrupts and addresses and whatnot, and the next day I removed the PROM, brought it to work, copied it, patched it up, and burned a new EPROM. I'm still shaking my head at that memory. Try calling a company today and ask a technical question.
But the real problem with almost-clones was (as you said) that in practice applications more often than not bypassed the "ABI" and went directly to the hardware, and admittedly that's not MS-DOS fault per se. The result was anyway that lots of software wouldn't run on almost-clones, especially if they moved around too many of the assumed interrupts (e.g. 80186-based PCs - they had some of the peripherals of the 8088/8086 integrated, just not exactly in an IBM PC layout). One system I ran across was an "enhanced" PC-like semi-clone, probably using an 8086 or something better - the local health services had just started a huge campaign where they tried to get everyone to volunteer for a health checkup, and they were followed up with a new one some years later, and on and on (it still goes on, to this day). Anyway, for that early start, they used this MS-DOS computer to collect and print information. But the printer didn't work - the PC was nonstandard. I went to the hospital and figured out why, and patched things and got it working (I don't recall anything today about what or how or even why I could).
CP/M applications though - they didn't, for the most part, bypass anything - maybe that's because people writing the software knew that the hardware could vary wildly. Screen-oriented apps like WordStar usually needed a machine-specific patch for that, but otherwise CP/M software was way more portable than MS-DOS software. PC software though - vendors just thought "IBM PC hardware" and that was it, for the most part.
That's easy: because the calls to the screen went through the terminal handling code; on MSDOS, for speed, many applications bypassed the MSDOS I/O and called the video hardware directly; this made things much less portable.
There were many MSDOS but not 100% IBM PC compatible machines made that got hit in the market because of this, such as the Zenith Z-100/Z-120 , TI PC, etc. If the memory map and everything else didn't exactly match the IBM BIOS setup the application would fail.
It had terminal capabilities (not to the level of termcap in Unix, but good) which meant that shrinkwrapped software like Wordstar would run on anything with an 8080, Z80, or NEC V20/V30 and CP/M. The Osborne 1's tiny screen was only 50 characters wide instead of 80, but software still ran on it.
It hit the sweet spot of abstraction for its time, and made it easy to write drivers for custom hardware that a new manufacturer might decide to make.