But what you're saying is that rebooting is somehow a magic cure-all that guarantees the system isn't infected somehow
Don't be condescending. I'm not saying rebooting is a magic anything.
Whether or not this matters depends on the threat model and why the attacker is interested in patching the kernel. For example, one purpose would be to disable other kernel security features, such as SELinux, or dm-verity. Most SELinux rules are configured and the configuration can be altered by root, but some are compiled into the kernel and can only be modified by modifying the kernel. Altering the persistent kernel image may not be possible for a variety of reasons (read-only media, SecureBoot, etc.). In addition, in security-sensitive and mission-critical contexts an unexpected reboot may well be noticed.
I don't understand your assertion about SecureBoot. Are you referring to some known vulnerability of some particular secure boot system? Given a decent implementation of secure/verified boot, an attacker should not be able to convince the system to boot a modified kernel image, which means that run-time modification of the kernel is the only option if the attacker needs to bypass some kernel security enforcement.
In general, the security model of a high-security Linux system assumes that the kernel is more trustworthy than root. The ability for root to modify the running kernel invalidates this assumption, which most definitely is a security issue.
In the context of a system without mandatory access controls there may not be any reason to care, since once an attacker has obtained root there probably isn't any limit to what he can do.