According to 0patch's FAQ, they don't patch the kernel for the specific reason you mention...
(source: https://0patch.zendesk.com/hc/en-us/articles/360011047979)
We currently cannot directly* micropatch:
Vulnerabilities in Windows kernel; this is due to the fact that Windows have an active self-defense mechanism for preventing kernel code modification called https://en.wikipedia.org/wiki/Kernel_Patch_Protection (formally named Kernel Patch Protection), which our micropatches would trigger and cause the computer to reboot. We believe PatchGuard adds negligible security value and there are known ways of disabling/bypassing it, but we have for now decided not to do that. It is possible that we'll revisit this decision in the future and advise users to disable PatchGuard (e.g., for end-of-support Windows 7 and Windows Server 2008 R2 servers with 0patch installed) in order to apply kernel micropatches, should these become necessary.
Vulnerabilities in .NET code; .NET applications are not compiled to native machine code but to managed code, which gets interpreted by .NET Framework's Common Language Runtime upon execution. We can, however, micropatch .NET Framework's native executables.
Vulnerabilities in Java code; while we can micropatch the Java Runtime Interpreter (e.g., java.exe), we can't micropatch Java applications (typically delivered as class files in a JAR archive) because they, too, are not in native machine code.
Vulnerabilities in scripted code; it would be relatively simple, technically, to modify scripted code in memory right before it got executed, but in contrast to binary files, which practically never get manually modified, scripted code is often modified by users or admins - and that makes it hard to identify a vulnerable version and pinpoint the vulnerability within. This is why we decided not to support micropatching of scripted code.