We like to think of running programs like the static source code that creates them. But they are really continually changing. Likewise the kernel in memory is NOT the same as the kernel on disk.
To quote Dijkstra in his letter "goto considered harmful"...
My first remark is that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to accomplish the desired effect; it is this process that in its dynamic behavior has to satisfy the desired specifications. Yet, once the program has been made, the "making' of the corresponding process is delegated to the machine.
My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible
From this I would infer that it is a bad idea to have a program or kernel in memory that isn't the result of loading the kernel from disk. If nothing else you want to know that you can reboot and end up with the same kernel as you are running now.
As a sys-admin you want to know you got a bonafide regular kernel at the end not some Frankenstein's monster because your live kernel had subtle differences to the one they patched.
And live patching is very hard indeed. It is technically impossible to automatically generate live patches
It's important to understand that program code effectively rewrites itself.
int X = 10;
In this code example
X=10 is never executed as code. The number
10 is placed in the location "X" by the compiler. When the 3rd line is executed at run time it replaces the value at location "X". It literally overwrites the value, meaning the number
10 disappears from the running program code entirely.
Now we try to live patch this with:
int X = 20;
What should X be patched to 20 or 15? Should we patch it at all or just leave it? We are not just changing code here we are changing dynamically generated values. You might think that because they are dynamically generated you might not need to change them, but if we don't change them do we know 5 or 10 is still a valid value in the new code? This cannot be done automatically!
In short there are techniques with associated tools that can create live patches, but using them and testing the result requires experts. Releasing these tools and expecting home users to understand how to use them is a good way for a lot of home users to screw up their system.