Just because a few phone vendors stop pushing out updates after a period of time after launching the phone doesn't mean that Android doesn't support it. This might have been a valid criticism about years ago. But one that should be aimed at vendors and not Android.
Regarding vendor support, Google launched an initiative called "Compatibility Program" which every vendor must now agree to. Part of the agreement means they are required to support OTA updates if they plan to use the Android OS.
https://source.android.com/compatibility/overview.html
So I don't know what you're basing this off of?
All of which could be fixed with something like Snappy where the OS component that is improved could be pulled OTA by the customer.
The meta discussion is that customer cannot do that because a handset maker has no way of reasoning about how changes to a component of the system will affect all handsets out there, and so new versions of android sit in all-or-nothing testing limbo at the handset QA lab.
I know for a fact (because I've created my own ROM) that Android's OTA system is fully capable of updating single components. And the update the user downloads is not the entire ~200mb Android ROM, it could be a small 1mb zip file that only updates a specific library. For example a security release updating only OpenSSL.
Why Google doesn't do this and prefers using a point release system - instead of rolling releases - is a complicated question. One that I'd be curious to hear the reasoning for.
One UX consideration is that the users need to reboot their phone since the OTA update writes to the /boot partition and then triggers a reboot into recovery mode. Then recovery mode will automatically install the new update (preserving all user data) then boots back into the OS. This would be annoying to users if they had to do it often.
But the same behavior exists for any OS updates on OSX, linux, etc.
It's not a viable method for updating generic servers however. An update system needs to do a lot more than just swap out a file. You need to know about dependencies, restart services etc. It's also important for real world usage to be able to skip one update for one reason or another.
It could be interesting for single purpose Docker containers which can be restarted at will.
I think this snappy scheme of Ubuntu might actually be what Android should have had from the start. It seems like it work in the embedded space when you don't want a traditional package manager.