There is also the fact that ACPI allows embedding executable code, which in effect allows system vendors to hide proprietary drivers on it. E.g. HID stuff such as brightness control or keys which do not (generally) need any kernel code to work and are generally impossible to define with DT unless they are simple single-purpose GPIO pins.
"Much of the firmware ACPI functionality is provided in bytecode of ACPI Machine Language (AML), a Turing-complete, domain-specific low-level language, stored in the ACPI tables.[7] To make use of the ACPI tables, the operating system must have an interpreter for the AML bytecode."[1]
And it's not like this was intended to truly be fully interoperable. "Maybe we could define the APIs so that they work well with NT and not the others even if they are open."[2]
This is semantics at this point, but ACPI "is" not executable code. It contains executable code in form of methods, but it is a structured container for many types of data (they are called "tables" for a reason). You could very well embed DT in ACPI and there are platforms out there which do that.
