(What is the policy here WRT reviving old topics? I bumped into this without noticing. Maybe next time I should delete my draft message and move-on?)
I think the big attraction of rPi compute modules is a guarantee that you will be able to get linux and kernel updates for a very long time.
If you go with an Android tablet the question I would ask is what SoC is in there, how many binary blobs go into the build, and for how long those will be updated (and whether Linux kernel 5.x is in the roadmap at all). You can create your own AOSP build but if there are binary blobs for radios when those cease to get updates your ability to update the kernel starts to get into question. Binary blobs for GPU may have a similar effect. (Google has been pushing the envelope lately, but the fundamental problem remains.)
The reason that Android phones only get 2-3 years of updates max is that by the time they’re sold the kernel is 2 years old, and has a 5-year guarantee of support (“LTS kernel support”), so there’s just 2-3 years left to go. The SoC vendor also stops updating the binary blobs for radio and other devices. In the end, the phone vendor can’t upgrade to a newer kernel due to sheer cost/benefit considerations and binary blobs, and can’t keep backporting security patches 'cause the security of that starts to be very questionable.
I haven’t thought much about what I would do if I had to build a connected device into a machine that has >5 year life expectancy… Maybe I would try to split the problem in two parts: a main device that handles everything local, and a separate communication device that is expected to be field-replaced after some number of years? (And obviously a well defined interface between the two.)