Historically this backwards compatibility was a competitive moat for intel – having a large supply of weird instructions with some undocumented behaviour thrown in makes it more expensive to make competing chips.
To be clear, I wasn’t claiming anything about operating systems. Merely that adding many weird instructions was a strategy intel used to try to make the jobs of amd and centaur and suchlike harder.
Some ARM systems (mainly servers) do support ACPI; allowing for one image to run on multiple processors and devices.
However… ACPI is apparently a pretty awful thing to implement. When it doesn’t work, or mistakes are made (looking at my own 13th gen HP laptop right now - borked ACPI tables means unpatchable broken sleep on Linux), then it’s pure frustration.
Device trees on the other hand are much more binary. Either everything generally works or it doesn’t at all. It’s a valid approach.
Flawed implementations of open specs can be worked around with things like quirk tables. A spec held hostage by a non-cooperating vendor cannot. In the world of ARM SoCs, bad vendors won't even provide a device tree, just a binary image compiled from a patched kernel.
nobody is a saint on this matter. both parties act the way they do to support their business position.
short-term support helps qualcomm sell more because their customers want to sell more phones to the same users. on the other hand, for the industrial partners there is an "LTS" model of support given (side effect being fairphone 5 https://news.ycombinator.com/item?id=37320800).
long-term support through backwards compatibility helps intel because they can sell new chips with the assurance that the ancient, unmaintained industrial software continues to run in a shinier box.