Google really doesn't have much of a choice in the matter. As big as they are, so far it doesn't appear that they've decided that this isn't an important enough problem to make their own phone SoCs. Qualcomm doesn't exactly have many competitors that could be endorsed over them. Huawei/HiSilicon is anathema in US, Samsung uses Qualcomm's Snapdragon over their own Exynos line in the US, Amlogic and MediaTek don't make high-end SoCs, and Apple only makes them for their own phones.

Qualcomm thrives off of the trend of people expecting new phones every year (or every 6 months in some cases). Since they target the mid and high cost devices, all they have to do is make the phone work for a two or so years, and most people buying those phones are going to have gotten bored of their phone by then.

This is one of the main motivations for Project Treble, which is to completely disconnect the phone's userspace from the kernel version it runs on. It's a hard challenge though. Qualcomm and the other vendors for these high turnover products aren't all that interested in supporting it, because they benefit from replacing phones frequently. If you've ever looked at one of the phone kernels, they shove way more into them than upstream would ever accept (the entire radio stack, graphics stack, quick charge logic, etc.). This tends to make the software running on Android phones heavily coupled to the vendor kernel.

The downstream kernels are full of terrible and disgusting hacks. They're just doing the bare minimum to get some semblance of Linux running on the hardware, then forgetting about it almost entirely aside from whatever random security hotfixes they're going to release, and refocusing entirely on their next design. There's no real effort being put into coding for long-term maintainability, that's left to the hobbyist community.