Just to try an explanantion from a different angle:
The device tree mechanism is an approach to fix "shortcomings" of the ARM architecture. In the x86 world all devices are discoverable. So the kernel can query the PCIe bus or the USB bus to know which hardware is present and loads drivers/modules accordingly.
In the ARM world it works differently: There is a huge variety between devices even though most of them are using the same basic components - just with a little bit variation. The device tree file enables the kernel to know about the present hardware (and some hardware-specific configuration, e.g. memory addresses).
Now for practical matters there is not much difference between a FDT and a "non FDT" kernel. You always need to present a device tree to the kernel but you can do that as a boot parameter (new uboot) or just "bake it into the zimage itself". The first method helps distributors such as bodhi because he can provide a single kernel image for multiple devices.
So what you choose to do is completely up to you. If you only care about one device no method is clearly superior. If you don't want to upgrade uboot, you have to use the "legacy" method.
And just for completeness:
"in other words, can i describe a given piece of hardware in both FDT and non-FTD ways?"
Sort of. Old versions of the kernel (before 3.16?) required that all device configuration was hard-coded into the C source code of drivers. Newer kernel versions require device tree files for the kirkwoord hardware.
Source: http://forum.doozan.com/read.php?2,24656,24666#msg-24666