When you can remotely prove that the entire boot chain has not been tampered with, it’s much harder to load cheat software in the kernel layer. Of course, still possible, just harder and easier to detect.

How does this address the fact that windows has 100s of badly written drivers that allow r/w to kernel? This seems to only stop the most advance cheats that actually execute at or before boot.

Secure boot addresses other specific security concerns that are unrelated to exploitable drivers. For instance, it eliminates a whole class of PatchGuard bypasses.

Sorry to derail, but how often does anti-cheat development involve buying access to a cheat just for the purpose of reverse engineering it? Is that pretty much most of the time or is there enough evidence collected from logs to be able to infer what was happening?

This is largely dependent on the passive collection capabilities of a particular anti-cheat. Sometimes getting a copy is useful to just to make 100% sure the detection you wrote works as intended. Sometimes it's because the techniques used are novel. Most anti-cheat vendors do this.

Not parent, but have seen this before, or some competitor/pissed off outed person/partner in crime/etc hands it to anticheat team.

Private cheats usually require being vouched in, sometimes with ID scans, sometimes physically shipping you hardware.