Windows drivers can be loaded and unloaded dynamically, yes. It's also possible that they're using "shut down" semantically and not literally, in that the driver is loaded but inactive while the game isn't running.
Isn't this the case for every major OS? I know FreeBSD device drivers can be (un)loaded on-the-fly. Same for MacOS. I assume it's also possible in Linux(?)
I'm not an expert, but from what I've come to understand, anti cheat is for the most part about making it as hard or inconvenient to cheat as possible. You'll never be able to stop it, but putting in hurdles for both the cheat developer and user is key to keeping it limited.
The huge problem is that cheaters are very willing to go to extreme lengths of inconvenience or even risk, as in running random cheats as kernel level drivers.
So anything that makes the developers have to bypass another hurdle and another component you can patch in your anti cheat "rootkit" gives you a small boost in the cat and mouse game.
Your component starting at boot makes it more likely the cheat devs and cheaters will have to do the same and have a more complicated setup.
I think making your cheat kernel level is a relatively minor hurdle compared to the lengths that people have been going with ML + hardware based cheats at this point. Maybe we need to stop the kernel anti-cheat just from a pure privacy perspective at this point, or make it an OS service you can implement as a user level module only, much like endpoint management and macOS. I get a feeling there is more to being in the kernel although.