This feels like, at best, getting back to where PCs already were, at least as a user. If a device tree can be embedded in firmware and fed to the booting system, then that's fine, it's just a minor implementation detail. If you need to go get a file and put it on your boot media, then that's extra friction. Likewise, I don't really care what the hardware's boot firmware looks like, but if I need a different bootloader per-device then that's a problem - can you imagine if Dell laptops and HP laptops needed different GRUB builds to work?
The reason you don't need to mess with GRUB or you BIOS when you change your hardware is that modern hardware interfaces have built-in discovery and resource allocation features. Before that you had to deal with pesky low level details like IRQ allocations and the like (which was a thing on PC not that long ago).
That's not really a feature of "PC" per se, it's a feature of USB, PCI etc... That stuff works exactly the same on ARM or anywhere else.
The things that need to be described in the device tree are generally internal components of the SoC and motherboard, things like IO expanders, SPI interfaces, serial interfaces, and of course the USB/PCI/... controllers themselves.
I think there maybe some confusion because of the term "bootloader". It's true that both u-boot and GRUB are bootloaders, but bootloaders in the ARM world have a lot more to do than PC bootloaders, they're effectively the equivalent of UEFI + GRUB, not just GRUB. You can write a simplistic boot sector loader for PC in a few hundred ASM opcodes, that would be a lot more difficult for the average ARM bootloader because there's a lot more to do before you can just call into Linux. In general you won't even have RAM or caches available when u-boot begins executing.
And I think it's actually a better design, because it means that proprietary built-in firmware crap is usually kept to a minimum on ARM: the BOOTROM usually just initializes the bare minimum to be able to load u-boot (or some other loader) into on-chip SRAM and then it's over. Of course that means that the loader is significantly more complex, but that complexity has to be some place or an other.
This is exactly the point OP's getting at though, and the exact "discovery" features you handwave away. If I write an OS (or bootloader) on x86 w/ BIOS/uEFI, I can easily query available memory and start using it. Meanwhile u-boot has to be told via an external resource how much RAM is available before it begins initializing. This is fine for embedded/bespoke development (since you'll know the hardware you're developing for and can make assumptions), but a pain for general OS development where you have to inform the bootloader/OS of every devices capabilities.
The consortium of like-minded manufacturers later went to help develop develop all the subsequent variants that persist to this day (PCI and ATX form-factor etc). The standardization benefited them greatly.
Now that ARM Holdings is owned by NVidia I hope Jensen Huang sees that if ARM is to take over the desktop it makes sense to bring that same level of standardization that allowed the PC industry (and NVidia) to dominate.
I think ARM Holdings needs to be the one to spearhead the initiative. It will help industry-wide adoption of ARM (for desktops, laptops and servers) which will benefit them greatly.
This is exactly right, but I fear the incentives have changed and we'll never again see something like the x86/IBM-compatible/Wintel world of "standard" inter-compatible systems.
As you say, it's a "why bother?" problem, and no manufacturer will want to bother: Apple has no interest in making it easy to run other OSes, Microsoft wants to sell you "Windows Surface" devices, not general-purpose computers, corporate buyers want a "secure" locked-down environment with a signed bootloader...
Are there any powerful stakeholders who benefit from interoperability?
I'm not convinced that this is necessarily true. They advertised running Linux VMs during their presentation, they made a tool specifically for installing Windows on Macs and they even recently stated how Windows on ARM Macs is really up to Microsoft. If you could run Windows on an M1 Mac, it'd really turn it into a powerful and power-efficient "do-it-all" machine, since you could still boot into Windows and run that niche Windows software that you need from time to time.
Notably the PC standard meant things were interchangeable, not "interlayerable". You picked a CPU, you picked an OS, you did not have to emulate or virtualize whatever you wanted on top of what was imposed on you. Imagine that 30 years ago someone pitched a PC that only runs a specific OS and the only way to run anything else is on top of that like an app. You'd think "ridiculous".
Today having a device that runs as sealed monolith both HW and SW wise, and all you can do is run stuff on top of that without the ability to replace anything is considered a good sign. Tells you where we're going.
Your answer is dismissive and misses the point because you nitpicked on one particular word I used that doesn't fulfill one particular and currently irrelevant scenario: Windows in Bootcamp. What about every other scenario?
Saying that "Apple will never allow you to replace macOS" is just plain wrong when they've been allowing you to do that for the past 14 years.
You might as well argue how Bootcamp doesn't run on iPads.
You'd still have to develop all the device drivers required for this custom SoC. After all, Linux doesn't need a license but without extensive documentation and support from Apple it's like saying you're free to challenge your boss openly, it's pedantically true, but it is impossibly impractical for most.
Unless Apple provides extensible documentation for 3rd party drivers to be developed for their SoCs it's just cheap talk from their side.
This isn't much of a "gotcha" - I do think it's outrageous that Apple gets away with selling these gimped iOS devices that only run Apple-approved software.
Would consumers stand for this with any other devices? A stapler where you had to buy staples from the manufacturer? A car that only drives on manufacturer-approved roads? A dishwasher that will only wash approved plates?
If Microsoft however succeed with their Surfaces like Apples does .. than maybe we are screwed. Luckily, they do not.
All those companies selling motherboards for gamers etc?
That was true ~15years ago but less so today. Modern PC EUFI bootloaders are bigger and more bloated than any uboot build in existence, and things like device tree support in linux means that you can support various boards with the same kernel (including boards that don't exist yet). Sure you'll probably still need custom bootloaders for most boards, but it's not like you can swap your motherboard BIOS/UEFI chips and expect them to work either. The PC "platform" with hardcoded physical addresses for your serial ports is nice if you're running DOS but it's not really relevant for modern operating systems which have to employ much more complex hardware discovery mechanisms.
It's true that on ARM it's still a bit anarchic and bespoke in practice but that's mainly because there's no reason to push for strong standardization when every vendor is building their own kernels for their own devices anyway.
But the tools do exist (on Linux at least, not sure about the other OSs), if desktop ARM becomes mainstream things could settle fairly quickly. It's less of a technical problem and more of a "why bother?" problem.