Grant Likely published article about ACPI and ARM at http://www.secretlab.ca/archives/151 . He acknowledges systems with ACPI are harder to debug, but because Microsoft says so, we have to use ACPI (basically).
I believe doing wrong technical choice "because Microsoft says so" is a wrong thing to do.
Yes, ACPI gives more flexibility to hardware vendors. Imagine replacing block devices with interpretted bytecode coming from ROM. That is obviously bad, right? Why is it good for power management?
It is not.
Besides being harder to debug, there are more disadvantages:
* Size, speed and complexity disadvantage of bytecode interpretter in the kernel.
* Many more drivers. Imagine GPIO switch, controlling rfkill (for example). In device tree case, that's few lines in the .dts specifying which GPIO that switch is on.
In ACPI case, each hardware vendor initially implements rfkill switch in AML, differently. After few years, each vendor implements (different) kernel<->AML interface for querying rfkill state and toggling it in software. Few years after that, we implement kernel drivers for those AML interfaces, to properly integrate them in the kernel.
* Incompatibility. ARM servers will now be very different from other ARM systems.
Now, are there some arguments for ACPI? Yes -- it allows hw vendors to hack half-working drivers without touching kernel sources. (Half-working: such drivers are not properly integrated in all the various subsystems). Grant claims that power management is somehow special, and requirement for real drivers is somehow ok for normal drivers (block, video), but not for power management. Now, getting driver merged into the kernel does not take that long -- less than half a year if you know what you are doing. Plus, for power management, you can really just initialize hardware in the bootloader (into working but not optimal state). But basic drivers are likely to merged fast, and then you'll just have to supply DT tables.
Avoid ACPI. It only makes things more complex and harder to debug.