> Where did you get this 6 month figure? Was that before or after the introduction of Project Treble, Project Mainline, the new security update system, etc?
Note: definitely not about Pixel outside of US (or even in the US if the phone was direct from Google).
You underestimate the time that it takes to approve updates, even taking into account what Google have done to speed up the update process.
The SoC and the Kernel
From the start, you need to have good driver/HAL for the specific SoC of the device. Qualcomm is very spotty on these: historically, the 8-series revives updates for up to two years (which is an improvement already considering that some older chipsets only has around 1.5 years of updates). This would be a minimal problem if it is Windows-style (where drivers are separate to the system) but Android is currently based on Linux, which integrates the drivers to the build. This means that major kernel upgrades are PITA or even impossible. Worse, Mediatek and other SoCs (aside Samsung, but they control it anyway) tends to only have a binary build of the kernel and as a device manufacturer you have to deal with it (that's why HMD cannot disable the DuraSpeed optimisation that Mediatek has put on it because Mediatek controls to a degree the whole device).
OEM-specific Customisations
It is no secret that OEMs modify Android hard, to the point that the modifications they have done is beyond the UI of the device. This means that patching of the devices takes time even when the OEM and the SoC manufacturer are responsive (as alluded to earlier, not already good). Worse of all, some fixes are in the mercy of SoC manufacturers as they affect the kernel.
OEM Priorities
If you have a flagship phone, congratulations! You receive patches monthly. However what if you are using a regular device (or even a budget device) from an OEM? Unless it is a device from an Android One OEM or a Pixel, you usually only receive updates quarterly, if at all (see SoC and the Kernel above). Plus, good luck contacting your manufacturer about this problem. This rather obviously slows down patching.
Carrier's Shenanigans
If you are not using a carrier-specific device, congratulations! The update should come to you as smoothly as the OEM wants to. But wheat if you bought your device under a carrier? Depending on your country, no significant difference to the non-carrier version or your devices' updates is being hold to by your carrier because they wnat to check it (apparently). Sometimes, your carrier is benevolent and really has a team that checks if the update will break something and authorise the OEM to release the update within a day or two. However, it is more likely that the carrier will slow down the process to the point that the non-carrier version is three versions ahead.
User Efforts
Well, that's the users' fault then. Not really relevant considering that Windows users tends to turn off updates.
What Google has done to mitigate this
Project Treble and Play Services Updates (aka Mainline) have reduced the time of patching of devices significantly and prevent a whole class of attacks (including the Stagefright component, which decodes media files and often has bugs in it due to it being mainly a third-party component). However, you have noticed that the SoC, and hence the kernel, still has teetering problems when it comes to updating. The good news is that Google has requested SoC manufacturers to "mainline" their drivers (aka including the SoC driver source code in the kernel, not to be confused with Project Mainline). However, that is just last month and it is still somewhat rejected by SoC manufacturers. Qualcomm have even promised to improve the updates, but we haven't heard anything from Mediatek et al. And that even excludes the pesky carriers who holds updates for no apparent reason at all.