Do you lock your door at night? Why? Anyone could just use a fireman’s axe and open it. Or they could just drive through your living room and steal everything.

For kernel-level anti-cheats its quite simple. Those in opposition to kernel-level anti-cheats likely view locking a door as a small task with minimal downsides, which could reasonably deter an opportunistic criminal, or buy you time to escape with your life or call the police.

They also likely view kernel-level anti-cheats as, for the benefits they provide, having too large of downsides. (providing a third-party company kernel-level access via a closed-source program)

If you’re concerned about privacy just dual boot windows in a separate SSD to play games and use Linux and Graphene OS.

In another thread in this comment section I mention UEFI rootkits and firmware implants (kernel-level access is strong starting point for this). Your solutions do not address these issues, which could be important to someone. (Depending on their threat-model)

If you tell me that all I need to do to negate the security concern of the kernel level anticheat is to run the dualboot windows partition…

…it makes intuitive sense that installing a kernel level anticheat would only affect the windows kernel it was installed on not the linux kernel on the other drive partition.

The intuition is incorrect as the kernel-level anticheats are not necessarily trusted. Operating systems interact with low-level hardware and firmware on the system. As such, it is not self-contained.

https://www.kaspersky.com/about/press-releases/more-elusive-and-more-persistent-the-third-known-firmware-bootkit-shows-major-advancement

There exists both UEFI bootkits and firmware implants. Its intuitive if you understand it like this: if there exists a communication pathway from (A) lower-privilege code -> (B) higher-privilege code, there exists the potential for vulnerabilities.

This is due to (A) now having an effect on the code execution for (B).