Not that this isn't a cool product, isn't it important to know your server can reboot?
You need to be able to reboot a server to patch it. If it's so important that your server do not reboot, it shouldn't be accessible by the general public.
Assuming that you run some sort of website or internet service, you need to be able to deal with failing hardware/software anyway. Either you big enough to have redundant servers or you small enough that a reboot won't matter.
I have a similar feelings towards backup and OS upgrades. You should be able to do a clean install and deploy your "stuff" on a blank server or vm somewhat quickly. If you 100% rely on say VMWare snapshots, you're doing something wrong.
Applying patches to the kernel to fix security vulnerabilities is orthogonal to knowing you can reboot your server. Rebooting servers is more than "will it come back up", it also includes all the headache of scheduling and the risk of what happens if it doesn't come right back up. But, because servers can and do crash, hardware needs to be upgraded, etc., you certainly need to know you can bring your system back up from a cold state.
Applying a hot fix means you are immediately protected from a vulnerability. Unless you are running at massive scale, few companies have an infrastructure that allows random servers to reboot (good on all those that do, regardless of scale!). Instead, most companies have systems and processes that make rebooting painful, especially for the IT guys who wind up working at 10pm on Saturday so they don't affect most people. And, until the reboot window opens up (whenever it is), your server is vulnerable.
Disclaimer: I work on the Oracle Ksplice team.
Or maybe your other server is already down for maintenance. Or you want both servers to be patched as soon as possible - simultaneously would be best.
You either have a long downtime or have a secondary ready to take over. I understand you're talking about avoiding to rely on a false sense of confidence; that's a good rule of thumb, but shouldn't get in the way of better solutions:
Test the secondary more often, and automate the recovery, and you'll cover more failure cases.
You don't have the resources for a secondary ? This means you're to small; neither this tool is for you; keep it simple, and just reboot.
Moreover, in some context is not desirable to perform a maintenance window until some designated moments like weekends. This means that you could leave your system vulnerable for up to a whole week.
I'd rather look through a week's worth of changes to work out what borked the restart than two years worth!
Then you restore from yesterday's backup. It's probably still on-site. If a kernel live patch fails, you might not notice for a long time.
Frequently exercising a feature is a good idea, especially when you depend on that feature. That's why exercising backup restores is important; you want that to work when you need it. Do you really need a production machine to boot when you need it? I think is a wrong target to optimize for, given that that failure more is already covered by backups cold/hot secondary as long as you do exercise them frequently.
That said, you do have a point about whether a live patch is reliable, but this doesn't have anything to do with whether increasing the average uptime of a host is a good or bad idea w.r.t to ensuring that the machine can start or not.
TBH I wouldn't personally feel much comfortable using this live update thing, but I have no experience with it. I'd be curious to know more though.