Binary drivers can be reverse engineered and reimplemented for the new kernel. This takes a lot of effort since it requires following a "proper" clean-room methodology when doing so for interoperability purposes, but is otherwise doable. A complementary approach is to forward port the minimum set of features that's required for Android 12 to the older kernel, in a way that carefully preserves the portions of in-kernel ABI that the binary drivers depend on.
I can see why Android was so popular with OEMs!
You can sometimes run 20 year old drivers, assuming same ISA and that none of the ABI has changed, which does in fact happen, just more rarely. Windows 10 is certainly not compatible with 100% of drivers from Windows 7, let alone XP (20 years ago is 2001, so Windows 2000 is actually likely).
SoC makers deliberately do this as a way to force phone manufacturers to buy new chips.
For example, if they release a chipset in 2020, it will ship with Kernel 4.14 (released in 2017). Why ship such an old kernel on brand new hardware you say?
Well Android 11 (also shipped in 2020) supports Kernel 4.14, but you can be pretty sure that Android 12 won't support 4.14. So that means that OEM's can't make android 12 work with that chip without a massive engineering effort (and by the way, a bunch of chipset blobs will be compiled against those kernel headers, so changing kernel versions is pretty much impossible).
So, the main reason to use a deliberately outdated kernel is to prevent last years chips running next years android release, without the chipset manufacturers permission and a share of the profits.