That is not entirely true (or at least needs additional clarification). Let's take the Windows Server scenario where security updates are delivered via hotpatches and coldpatches, targeting N reboots per year. Let's say N = 2 and we're aiming to reboot in Jan and July. Once a machine receives its Jan security update (via coldpatch) and reboots, subsequent monthly security updates (until July) will be delivered via hotpatch. Take ntoskrnl.exe. The Feb hotpatch for ntoskrnl.exe applies to the "base binary" (coldpatch) delivered in Jan. The March hotpatch for ntoskrnl.exe includes the fixes in the Feb hotpatch (it's cumulative) and also applies to the same base binary, and so on. If this machine happens to reboot in April e.g. after receiving the April hotpatch package, it will load up the base binary from Janary and apply the April hotpatch to it. So, we always load the base binary and apply the "current" hotpatch to it (if one exists). When the July security update arrives, the machine will be rebooted and the July version of all binaries will be the new base binaries to which subsequent hotpatches will apply. So, if the machine reboots before receiving the August hotpatch package, it will not apply any hotpatches.
This scheme is important to control the test matrix. Each hotpatch is cumulative and applies to only one base binary.
I don't know the full technical details of 0patch, but I don't see how it can reliably work given the defences we have implemented in Windows against unauthorized code patching in kernel-mode (like PatchGuard and especially HVCI in recent versions of Windows).