Previously you had a bit of boilerplate code that did much the same. Either way it doesn't actually solve the issue, because you still need the dts file, there's no hardware discovery.
(ok that's a bit of a stretch, some of the busses and things like I2C are discoverable, but you need a map of GPIOs, UARTs etc etc)
The Linaro kernels ("Linaro Stable Kernel" is the keyphrase) boot from devicetrees (aka FDTs). Not sure how much of that is upstreamed, but devicetrees are pretty standard in the ARM world as far as I can tell. (Also, in general if you're doing Linux stuff on ARM, Linaro is the place to look for everything).
Edit: actually, that link isn't very relevant - I just lazily googled "linaro devicetree". But you should be able to find more info!
I'll investigate Linaro at some point, if that's more of a hotbed of ARM development.
https://lwn.net/Articles/560523/ https://lwn.net/Articles/561462/
But you do still need the dts, so while it makes device support easier, it doesn't solve the problem of discoverable hardware and you still need board specs etc, either from the original manufacturer or reverse engineered.
Either way, I was talking about what we have now, and even if we have device tree now it doesn't solve this problem without other pieces to the puzzle. And that's without even getting on to the mess of closed source graphics drivers that exist in the arm world.
Please don't think I'm trying to say we can't have a situation like the OP wants, I'm just trying to explain why we don't.
Graphics are also very non-open at the moment, so it can be very hard to install other operating systems in a useful way for that reason.
In theory though, I agree entirely, that would be nice :)