When I have some Linux distribution installed on a x64 system, for example I can pretty much unplug my storage drive put it into another x64 machine, install a few HL drivers, like the graphics driver and it will most likely run without any hassle.When it comes to ARM systems, especially ARM SoCs, like smartphones of any sort, there is a completely different picture. There is a different build of the same OS (for a example a OEM Android distro) for every singly smartphone. My question is: Why is that?I understand that unlike PCs with there standardized architecture, there are lots and lots of SoC chips and architectures. But with the device tree in mind I ask myself why there isn't a way to put the device tree, as the hardware description, together with the bootloader on some ROM chip and build the Linux OS independently from any hardware specs, at least within some defined limits. 
Why are ARM SoCs so seemingly hard to handle with the Kernel?
kernel;arm;device tree
I ask myself why there isn't a way to put the device tree, as the hardware description, together with the bootloader on some ROM chip and build the Linux OS independently from any hardware specs, at least within some defined limits. Answer: Cheapness. Nobody wants to pay for the ROM chip. The SoC has a boot ROM in it, but the device tree varies depending on the circuit the SoC is in, so that's no good. You'd need a separate BIOS chip like x86 boards have to make this work.You can sort of make it work by treating the SD card that most ARM boards boot from as the BIOS chip; just put U-Boot and the device tree on it, and have U-Boot load the kernel from a USB drive. Then the USB drive would be (fairly) portable from ARM board to ARM board.In terms of optimization, while you can compile for ARM generically, it really pays off to target a specific processor (much more so than on x86_64).