I feel there's a trust problem here. I'm no Windows dev, so I don't know all the details, but since MS enforces secure boot, they have to play by the rules: Only trusted code can be executed with very high (kernel level) privileges. That's one of the reasons why they want to enforce signed binaries. Especially for drivers and other stuff.

On Windows that means only entities that MS trusts are allowed to execute high privileged code. Otherwise you wouldn't get your binaries signed by MS (or co-signed, or white-listed or whatever aproach they take in this scenario) and without signature, no execution. You need to trust MS, but you need to trust them anyways, as they control the chain of trust on boot and also create the very kernel you're running on. If they wanted to cheat you, it's be easy for them.

On Linux it's a bit different. Linux has the aproach that any user with root privileges is trustworthy. That's good for me, as I get a say on what runs on my hardware and how it runs. But for the anti cheat vendor that's now a huge problem, because a random person is now the one controlling the kernel, its integrity and the chain of trust on boot. Worse: It's usually the very person they're trying to observe if they're cheating. But how do you do this, if they (theoretically) have full control over the kernel and can run arbitrary kernel modules?

Now, I'm not saying that there's no trust in the Linux kernel and Windows were more secure - just that there are completely different assumptions about trust and trust boundaries that may lead to severe headaches for the anti cheat vendors.