Sadly it seems in a sense RH is funding both sides at the same time, as many of their employees are the very source of the "exciting" developments happening in the Linux ecosystem these days.
Thing is though that in a sense the Linux community has painted itself into a corner. Thanks to the likes of RHEL, Ubuntu LTS and Debian Stable, there is little reason for the upstream to be anything but "exciting".
In user-space there's even more interesting developments, you just have to look a little closer. ;)
Mind you, ask yourself: why do you need it?
If it's for apps, isn't the point of these platforms to not need to care about individual instances?
If it's for data, don't you have an existing way to manage HA or parallelism?
Kubernetes has been more open to absorbing sticky, less-factored workloads than more opinionated platforms are. Red Hat have definitely made that point to folk whenever we and they are competing for business.
I had occasion to look at CRIU relatively closely in recent times. It is, as I said, early days, with annoying corner cases that need someone to patiently fix and polish (we ran into problems with networking, environment variables and process IDs).
In your case it will probably become attractive in the next year or two, because both Red Hat and Docker Inc (which is why I mentioned Docker) are touting checkpoint migration as a feature and I expect both will devote engineering effort to productionise it.
As an aside, if you're using the JVM, there was a really clever paper on coordinating the JVM G1GC and CRIU to greatly improve migration time: http://www.gsd.inesc-id.pt/~rbruno/publications/rbruno-middl...
edit: [0] Which is why as usual I am a dimwit for starting with answers instead of questions.
DragonFlyBSD has had process checkpointing for more than 10 years.
https://www.dragonflybsd.org/cgi/web-man?command=checkpoint&...
While the functionality is admittedly & unfortunately quite limited, there are no technological reasons this couldn't have been furthered in the meantime given sufficient funding/dev time, etc.
For example, not being able to restore sockets of any form (such as TCP sockets) is a massive limitation that CRIU doesn't have. userfaultfd allows for CRIU to have a slave process that is used as a source of lazy page loading from another machine (allowing for viable cross-host checkpoint/restore with on paper no downtime). And you can use CRIU to checkpoint/restore entire containers (DragonFlyBSD doesn't have Jails, but it looks like you can't even checkpoint process trees).