I'm personally (uneducatedly) mostly for it because I like the way things "just work" on PCs. No matter what components you put on, the thing will boot. A sibling mentions that this is due to ACPI - I guess then I want that too.
Needing a separate build for nearly every different SBC sucks and I'm happy about anything that will broaden compatibility here.
It's entirely because it's expected in PCs and not expected on SBCs. Devicetree exists and can solve this problem, but it means the SBC and ARM SoC vendors would need to upstream their drivers like x86 vendors do. Until you have that ACPI vs devicetree is irrelevant for the purposes of improving this situation.
I'm reasonably confident that firmware/boot and drivers are orthogonal; consider that there are PCs with normal UEFI boot that will happily boot any Linux image you want but it'll come up without drivers because nobody's written them, or on the other hand the Raspberry Pi has open source drivers[0] but the boot situation is still its own bizarro thing that's unlike any other machine so you can't boot the same USB stick on a Pi and anything else[1].
[0] Weirdly not all upstreamed last I looked, but mostly.
[1] I mean, you might be able to put a Pi-compatible bootloader and, say, a UEFI+ARM bootloader on the same stick, but I mean with a single boot path.
This is a narrow view. There are more operating systems out there than just Linux. Standardizing peripherals the ways PCs have done would have many benefits. Device tree basically forces operating systems to need per board images instead of a generic image that works on most boards. This doesn't scale well, especially on operating systems without a stable driver abi.
There's nothing about device tree which forces this. It's just how it's normally used because of said constraints. The ideal device tree situation would be it is provided by the SBC vendor and then passed into the generic image, just like ACPI. The reason this isn't done is this generic image doesn't exist at the moment. Switching to ACPI still means this generic image doesn't exist.
It's the reverse. DTs allow having a common image, where just the DT differs (and can be selected on boot, or passed from FW if it's not part of the OS image).
> Standardizing peripherals the ways PCs have done would have many benefits.
So, Linux's implementation would work well, whilst Windows has to pretend to be Linux in order to have it work mostly kinda unless the device explicitly supported Windows?
Needing a separate build for nearly every different SBC sucks and I'm happy about anything that will broaden compatibility here.