Relevancy filtering is more for network traffic optimization, it doesn't really help with cheating in most cases. In a FPS, for example, the actors the cheater most wants to know about are almost always also network relevant.

But taking a step back, for fast games (like an FPS), the latency requirements drive you to send semi-secret info to the client (like the positions of other players), and so that's where things start to break down. But the traffic in the other direction is a problem too, as you have all of the scenarios in which the messages to the server (e.g. aim info, timing of weapon of firing) can be spoofed or engineered.

The motivation for the client-side anti-cheat systems is to extend as far as possible the envelope of what is considered trustworthy - i.e. if they can't solve the latency problem, then they try to make the client more trusted.

It's impossible to completely solve the problem, so it's about finding a solution that solves as much of the problem as possible. Unfortunately the main thing going for kernel anti-cheat is that most users don't care that they have to let someone root their machines to play a game, though the tide would likely turn if there were a high publicity exploit.

"All cheats can be trivially solved server side, as long as I exclude all games I don't like, which are also the games where the problem is hardest to solve and most relevant to the discussion."

Server side can not do anything about ESP or aimbot as they rely only in information that the server must provide the to the client. ESP can be curbed somewhat by obfuscating objects not in their view, but how effective this is depends very much on map geometry as the server must send it at some point. It works okay in games like CS/Valorant (that already has it implemented for years) but does basically nothing in Battlefield/Apex/Escape from Tarkov as they have very open maps. Aimbot can be configured to be pretty much indistinguishable from the best players.