But "no BOIS or ACPI" and requiring the kernel to support each individual board sounds exactly like the problem is the ARM architecture in general. Until that's sorted it makes sense to be wary of ARM.

It's not a problem with ARM servers or vendors that care about building well designed ARM workstations.

It's a problem that's inherit to mobile computing and will likely never change unless with regulation or an open standards device line somehow hitting it out of the park and setting new expectations a la PCs.

The problem is zero expectation of ever running anything other than the vendor supplied support package/image and how fast/cheap it is to just wire shit together instead of worrying about standards and interoperability with 3rd party integrators.

What is ACPI other than a DTB baked into the firmware/bootloader?

Any SBC could buy an extra flash chip and burn an outdated U-Boot with the manufacturer's DTB baked in. Then U-Boot would boot Linux, just like UEFI does, and Linux would read the firmware's fixed DTB, just like it reads x86 firmware's fixed ACPI tables.

But - cui bono?

You need drivers in your main OS either way. On x86 you are not generally relying on your EFI's drivers for storage, video or networking.

It's actually nice that you can go without, and have one less layer.

It is more or less like wifi problem on laptops, but multiplied by the number of chips. In a way it's more of a lunux problem than arm problem.

At some point the "good" boards get enough support and the situation slowly improves.

We reached the state where you dont need to spec-check the laptop if you want to run linux on it, the same will happen to arm sbc I hope.

Is a decision of linux about how to handle HW in the ARM world. So is a little like in the middle.