There are a couple reasons, that when combined result in the current unfortunate situation:

Embedded hardware development technique spilling over

Anyone who ever worked with embedded hardware might will likely confirm that the way how software is developed and deployed is often far from ideal (ancient kernels/tools/compiler, hacky deployment tools and general lack of standardization). This still generally works out for fire-and-forget-embedded devices with infrequent or even no firmware updates once deployed in the field.

But things generally fall apart when you try to apply the same techniques to what is basically a mass market small computer used by regular people used to desktop update schedules. The embedded techniques just no longer scale.

Lack of BIOS & device enumeration APIs

X86 PCs and servers generally have BIOS (old style or EFI based), which is a built-in minimal OS that when the computer starts up brings up the hardware, checks it's working correctly and then hands control over to the really OS (Linux/Windows/etc.). The BIOS also provides some hardware enumeration APIs, such as ACPI, that the OS can use to enumerate hardware on the given machine and act accordingly.

There is no such thing on mobile ARM devices.

And that's a big problem - the Linux kernel needs to known on exactly which hardware it will run and do all the low-level configuration and checking itself. There are generally also no device enumeration APIs so you need to hardcode the exact hardware configuration to your kernel or else stuff will not work.

This was the reasons that it used to be the norm in the past that there was separate kernel fork for every specific device variant. Compare that with situation where there is exactly one kernel a distro, such as Fedora, maintains and that works on all hardware Fedora supports thanks to BIOS handling all the low level hardware configuration details.

BTW, a bit of trivia - who can we thank for universal availability of BIOS & ACPI on x86 devices ? Microsoft, really! They needed one OS image that can work on all the hardware and thanks to the dominant position of Windows x86 hardware companies had no choice than to provide what was needed for that, which was BISO, ACPI & co.

Linux then basically piggy-backed on that.

Thankfully, situation seems to be hopefully improving on the ARM front. There is now the device-tree mechanism where the Linux kernel get a blob describing the current hardware. This way a single kernel can handle multiple versions of BIOS-less hardware. On the other hand the kernel still needs to do all the low-level hardware setup. Also some hardware, generally ARM servers, has EFI-based bios (see SBSA for more details).

Time to market

Mobile device market seems to be still moving more quickly than the PC market, so how quickly you can get you device out of the door with some new features/better performance/lower price than the competition. That includes hack to hell software because there just was no time to do things properly. But hey, you were first!

Planed obsolescence

The hardware vendors generally get the most money from you when they sell you the device - they have no real monetary incentive to keep supporting the device afterwards. Actually the opposite - if they quickly stop supporting it, you are more likely to buy a new one, possibly from them.

This is why I really like the Sailfish X subscription model - it has a chance to break this vicious circle.

People still generally don't care

General users don't seem to really care about both running unsecure software and throwing the device away when it no longer works for them. That again does put less pressure on hardware manufacturers to do things properly.

People seem to care more about not throwing away desktop/laptop hardware - maybe because of prior experience or because it's larger ?

Google vendor lockin

Some issues on Android also stem from the meddling Google is doing to gain ever more control over Android via the Google play services API which more and more Android applications depend on. Another vector which Google uses to control Android hardware manufacturers is the Open Handset Alliance. See the Arstechnica article for details of how this all works.