That's just the thing, there is no 'ARM CPU'. There is a ARM ISA, and some Core spec's, not a real 'ARM CPU'. Maybe a complete ARM SoC design you can buy, but nothing like an interchangable CPU, let alone socketed with multiple vendors.
If it's ARM-based, it's probably an embedded, closed, proprietary system with zero design need for 'compatibility'. With x86-based boards, you know there will at least be some sort of standard BIOS of EFI interface, a set of busses, a minimal number of devices that will behave and work the same on almost all systems. With ARM, there is no such thing, except for most parts of the ISA, and that's simply not enough.
It's a bit misleading: he's referring to the Cortex-M series of ARM microcontroller cores, which do not implement the core ARM instruction set but instead only implement the Thumb series of alternate instruction sets that are optimized for code density. There are older ARM cores that pre-date Thumb and only have the core ARM instruction set, but there would never be a situation where you'd want to take binaries compiled for one of those devices and run them on one of the microcontroller cores.
There are however, plenty of other variables across the ARM ecosystem that can cause real headaches, like the different versions of the VFP floating point co-processor.
Cortex-A, Cortex-M, Cortex-R have different targets, ISA, System organization as far back as their origination. Not sure why you'd compare them, I was obviously talking about processors within the same segment, Cortex-R7 is backwards compatible with previous versions, Cortex-A72 is backwards compatible with previous versions, Cortex-M3 is backwards compatible with previous versions.
x86 chips are themselves almost complete SoCs at this point [1]. That's why you can buy things like Compute Sticks, after all.
It's true that Intel is by far the largest supplier of x86 chips, and so you get some level of "standardization" with things like Intel HD Audio. But that's more the effect of a monopoly than anything else. Competition breeds fragmentation, but given the choice I'd rather have competition.
While true, it wasn't always that way. The IBM PC with the BIOS was basicaly one of the first layers you'd have to be compatible with, and up to UEFI systems with CSM for BIOS emulation, it's been supported for about 30 years.
There was a time where the chipset did a lot more than it does now. Right now, it's the PCH or whatever it's called, and you even have those SoC's where you don't even need that anymore. You used to have the possibility of a standard BIOS with a chipset from someone else (SiS for example) and audio from someone else, as well as PCI controllers, PICs, RTCs, HBAs, UARTs, and CPU's. Or have an Intel chipset with a non-Intel CPU, also possible. You could even make a complete x86 system with no Intel chip inside (pun intended). Right now, that's something you probably can only do with an AMD system and that's about it.
If it's ARM-based, it's probably an embedded, closed, proprietary system with zero design need for 'compatibility'. With x86-based boards, you know there will at least be some sort of standard BIOS of EFI interface, a set of busses, a minimal number of devices that will behave and work the same on almost all systems. With ARM, there is no such thing, except for most parts of the ISA, and that's simply not enough.