The interesting part will be when embedded systems start coming with UEFI and the whole device tree concept is given a companion for ARM in favor of those system tables. It would be rather stupid to take a hard, fast stand against system tables in favor of device trees when an industry standard firmware simply doesn't supply them (or force UEFI firmware implementations to implement device tree just to support Linux..)
After all, ARM (as in the company) are pushing UEFI not just as a way to boot Windows, but as a better, more unified and standardized bootloader which U-Boot and many other "alternatives" simply cannot do (since on every SoC there tend to be different ways of handling precisely the same thing in U-Boot unfortunately).
Personally I would rather we did away with the device tree concept as SoCs are painful to implement in a device tree - what usually happens is Linux drivers are written then a device tree spec is written for that device, which includes values which should never need to be put in a device tree. What is missing from the device tree is usually hardcoded into the driver, and usually that's stuff you may actually want to be 'dynamic' in a device tree. It worked great for m68k, SPARC and PowerPC but those implementations really WERE dynamic, and supplied by the bootloader (OpenPROM or later OpenFirmware) based on a real-time introspection of the hardware at hand, not preconfigured and unchanging except for a few notable hacky bits which some bootloaders can shove values into. Static device trees built at kernel build time rarely, if ever, match the exact board design, and the usual theme from China is you get a board, write a device tree and 3 weeks later a new board is out which needs a different device tree. Plugging in a single kernel with 10 device trees on flash or disk, to select in the bootloader depending on board revision, is quite a painful concept.
We have an opinion round here at work that the device tree should be written by the board designer - not the SoC vendor (although they should be involved) and certainly not the driver author. The board designer is the only one who knows what is connected and what information is truly, truly important. The board designers knows what he WILL change later. And worse, the current specification of pinmux details in the device tree is truly, truly moronic from an electronics design point of view. The vast majority of hardware designers would rip a hole in spacetime if you told them you are going to make them wait 15 seconds to configure I/O direction and pad configuration. This is stuff that should be configured at a very low level right as the chip is powered on, not at Linux kernel init time.. the restriction this puts on hardware designers to only use the "default" pin configurations until some late time in boot for fear of driving an output pin on the SoC to an output pin on a peripheral chip where this is not electrically sound, is not a fun thing to have to work out. The device tree SHOULD report the CURRENT configuration of the harware, not dictate what the configuration SHOULD be in order for everything to work.. in supplying configuration data for changing the operation of the chip, the flattened device tree concept has essentially proven that it is completely flouting the very concept that made device trees (as a specification of running hardware and API) such a great idea in the first place.