This is how Linux works too, the issue, as I pointed out, is just device tree <-> peripheral driver mismatch.
In the sense of "supported" where the peripheral drivers are upstreamed _and_ the Device Tree matches the code that was upstreamed, this is exactly how Linux works. It's just that as the article documents with Rock64, this is sometimes not an easy combination to find. I'd imagine that NetBSD actually has the same issue with respect to needing a "supported" Device Tree for a given "supported" hardware version - there are probably interim Device Trees that will not work at all.
The issue is that the Device Tree and kernel are both moving targets which often don't match, because fundamentally the Device Tree is just a configuration file for the peripheral drivers and the details of the interface contract between the Device Tree and peripheral driver can change at any time.
The same issue would exist for ACPI too - as several posters have pointed out, the issue is mostly cultural.
x86 has a "plug n play" culture - hardware is sold mix and match and has to work with generic CPU/motherboard/firmware combinations, so the platform needs to be able to enumerate devices and allocate resources on the fly. Drivers are written from the ground up to work with what bus enumeration gives them and not to make naive assumptions about the configuration of system memory. Plus, PCI devices all have a standards-constrained communication mechanism with the host, as opposed to ARM peripherals, which can be any given combination of register-mapped, memory-mapped, interrupt-mapped, or multiplexed through other hardware.
ARM systems culturally have never had this constraint, so many drivers rely on hardcoded assumptions that break when they are introduced to another SoC. And for ARM, this is only getting worse as instead of making peripheral drivers more generic, vendors are instead building blob-HALs. I'm not sure what the solution here is unless the buy side (OEM server integrators, phone vendors, set top box manufacturers, SBC vendors, etc.) start demanding improvement. In the case of the Pi, the Pi folks instead have been slowly chipping away at making this migration themselves (i.e. slowly replacing DispmanX FKMS with native KMS), which is An Approach but maybe not A Great Approach.
This is certainly the dream of DeviceTree, but I don't see how this can work, given that "Linux" generally requires a different device tree depending on both the kernel version and which specific drivers are employed. Perhaps for specific ARM boards with a very high degree of maturity this is possible, but for example even for Raspberry Pi, a completely different set of DT overlays are required depending on the specific graphics driver configuration which is desired (KMS/FKMS/proprietary VideoCore etc.).
In the sense of "supported" where the peripheral drivers are upstreamed _and_ the Device Tree matches the code that was upstreamed, this is exactly how Linux works. It's just that as the article documents with Rock64, this is sometimes not an easy combination to find. I'd imagine that NetBSD actually has the same issue with respect to needing a "supported" Device Tree for a given "supported" hardware version - there are probably interim Device Trees that will not work at all.
The issue is that the Device Tree and kernel are both moving targets which often don't match, because fundamentally the Device Tree is just a configuration file for the peripheral drivers and the details of the interface contract between the Device Tree and peripheral driver can change at any time.
The same issue would exist for ACPI too - as several posters have pointed out, the issue is mostly cultural.
x86 has a "plug n play" culture - hardware is sold mix and match and has to work with generic CPU/motherboard/firmware combinations, so the platform needs to be able to enumerate devices and allocate resources on the fly. Drivers are written from the ground up to work with what bus enumeration gives them and not to make naive assumptions about the configuration of system memory. Plus, PCI devices all have a standards-constrained communication mechanism with the host, as opposed to ARM peripherals, which can be any given combination of register-mapped, memory-mapped, interrupt-mapped, or multiplexed through other hardware.
ARM systems culturally have never had this constraint, so many drivers rely on hardcoded assumptions that break when they are introduced to another SoC. And for ARM, this is only getting worse as instead of making peripheral drivers more generic, vendors are instead building blob-HALs. I'm not sure what the solution here is unless the buy side (OEM server integrators, phone vendors, set top box manufacturers, SBC vendors, etc.) start demanding improvement. In the case of the Pi, the Pi folks instead have been slowly chipping away at making this migration themselves (i.e. slowly replacing DispmanX FKMS with native KMS), which is An Approach but maybe not A Great Approach.