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.
> There is a ARM ISA
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.
AFAIK, ARMv7 in user/system mode is backwards compatible with ARMv5 at-least. Even AARCH32 claims so.
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.
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.
It's the IBM PC architecture, not x86, that is the de facto standard. It's reasonable to prefer that to the relatively recent, and poorly adopted, device tree stuff that you see in the embedded ARM world. But let's not ding the ARM CPUs themselves for that.