The problem isn't with device trees. And actually, ACPI is just like DT really (but more complicated because it has "methods" in addition to just properties).
The difference is that you don't see it so much because the PC vendor has already written the ACPI tables.
The major difference on X86 is that it is (for historical reasons) much more standardised at the hardware level than on ARM (at least on embedded ARM, there is more standardisation in the ARM server space). It also makes more use of discoverable busses like USB and PCI so the parts that need to be described in ACPI are smaller than the parts that have to be described in DT on ARM (as much is either "implicitly standardised" or on a discoverable bus).
And that is because all PCs are basically the same whereas there is a huge variety in ARM SoC hardware and boards, mostly for understandable reasons (there are a huge variety of use cases and price points in embedded systems).
If you were to build an embedded X86 system not using a PC architecture (North bridge, South bridege etc) but using the processor and your own design you would have exactly the same problem.
That said you don't have to have "hardcoded firmware images for every single device" in the embedded ARM world.
I build an in house BSP for a product family of ~15 devices based on 3 different SoCs and we have a single kernel and userspace (Debian based) for all of them. All the DTs are on the boot partition and the bootloader selects the right one based on hardware information (typically a small EEPROM).
The only part that has to be different is the bootloader itself (and then not different for every device but for each SoC) - so we have 3 bootloaders all supplied as part of the BSP and when building the install media we say which one to write.
Even that, in theory, could be avoided, at least on SoCs with the same ISA by improving u-boot a bit to make stuff like clocks configurable from data (the u-boot device tree) like the kernel already does. This may one day be possible once u-boot completely adopts the driver model.
The major difference on X86 is that it is (for historical reasons) much more standardised at the hardware level than on ARM (at least on embedded ARM, there is more standardisation in the ARM server space). It also makes more use of discoverable busses like USB and PCI so the parts that need to be described in ACPI are smaller than the parts that have to be described in DT on ARM (as much is either "implicitly standardised" or on a discoverable bus).
And that is because all PCs are basically the same whereas there is a huge variety in ARM SoC hardware and boards, mostly for understandable reasons (there are a huge variety of use cases and price points in embedded systems).
If you were to build an embedded X86 system not using a PC architecture (North bridge, South bridege etc) but using the processor and your own design you would have exactly the same problem.
That said you don't have to have "hardcoded firmware images for every single device" in the embedded ARM world.
I build an in house BSP for a product family of ~15 devices based on 3 different SoCs and we have a single kernel and userspace (Debian based) for all of them. All the DTs are on the boot partition and the bootloader selects the right one based on hardware information (typically a small EEPROM).
The only part that has to be different is the bootloader itself (and then not different for every device but for each SoC) - so we have 3 bootloaders all supplied as part of the BSP and when building the install media we say which one to write.
Even that, in theory, could be avoided, at least on SoCs with the same ISA by improving u-boot a bit to make stuff like clocks configurable from data (the u-boot device tree) like the kernel already does. This may one day be possible once u-boot completely adopts the driver model.