Game Development

No, and I said (perhaps I didn't make it clear or I may be hallucinating lol), client side anti-cheat by itself is equally as ineffective as server side anti-cheat by itself at stopping cheating, because they both only catch some cheats. They both need to be used together in order to ensure a nearly cheatproof game. (Ignoring Walled Gardens like new, unjailbroken console environments).

Anti-cheats need Kernel access so that a cheater cannot try to disable or bypass the anticheat easily. I mean, nothing with a point of entry is totally secure, but with a good enough deterrent people that want to get in will think it is totally secure or not worth their time. At that point, with so many deterrents, developers of the anti-cheat software should be able to determine how a cheater that gets around their software does it and devise a patch for the vulnerability.

Dealing with cheating is always reactionary. You cannot preemptively ban someone for cheating, you have to actually wait for them to cheat. Kinda like the movie Minority Report (greata movie). But to make it a lot easier for game developers, setting up as many guard rails as possible help them to focus more time working on the actual game instead of dealing with cheaters. Its a necessary evil, and the consumer should decide for themselves if they want to install that on their system or not.

I do think that all anti-cheat software should only actually run when the game that needs it is running. I also think that games should have a label that say, vaguely, how invasive the anti-cheat is. Knowledge is most of the battle against cheaters, so telling them the exact anti-cheat methods could be detrimental, but at the same time consumers have the right to be informed about the kind of software dependencies a game might have.