From what I've seen, the automatic update system is sweet. I'm really glad the team decided to tackle one of the largest blockers to adoption (IMO) which was providing security updates.
Thing is though that on ChromeOS, there is a core part that never gets updated. This is why only certain newer Chromebooks could get Android app support. Because the way they implemented it required a minimum Linux kernel version.
And over on the Android side you still have the issue of OEM and carrier meddling in the update process.
So i fear that this platform will be beset with similar issues once it starts to spread beyond the realm of enthusiast dev boards.
It's possible to update kernels in ChromeOS (there are A/B partitions for them just like for pretty much everything else). The main question is how much effort should be invested in bringing "ancient" (in computer time) SoCs up to speed to support a use case (Android) they might not be powerful enough for (both CPU speed and memory availability).
After all, the SoCs in use are much the same ones that are powering said Android devices already. The overhead of the ChromeOS addition should be minimal.
Also, there might be additional requirements for the GPU - all that map-Android-display-to-Wayland stuff that is used to get Android output into Chrome OS windows requires a bunch of capabilities that aren't necessarily efficiently implemented on older SoCs. Rendering to offscreen buffers is a feature that GPU designers provided and improved bit-by-bit and only with lots of market pressure.
A couple hundred hours of work to bring the kernel forward (and test that it doesn't introduce regressions) for a feature that will only frustrate users (because it's there, just not practically usable) may not be a good investment.
With this model at least you're not part of botnet for sale, so that's a good thing.
If you want to avoid state actors you have to live the lifestyle of Stalman or something similar.