Data is being limited though, like not sending opponent location data unless the client can see them
It begins to fall down when you think in terms of interpolation and movement, if the server had to confirm your every movement it'd end up very jittery and feel awful as you ping back and forth between where your client state thinks you are and the server state thinks you are.
Even the client is kind of guessing (visually) where it is a lot of the time, at least until the next physics or update tick comes in and all this means that the server is going to be doing a hell of a lot of guess work about the state of the clients.
This article helps with reasoning around what a game is doing per-frame: https://gameprogrammingpatterns.com/game-loop.html
Certainly though, I think in this day and age, for slower games you could probably do a better job of this on the server though -- and I'm sure people are working on it.
There are two main issues:
1) You typically want to let player's machines have a little knowledge the player doesn't, because if they peak around a wall, they should see an enemy, without having to wait for a round-trip before getting the information of the enemy they can see. Games often give out too much of this kind of information, but that's because it is computationally hard to figure out if a player can "almost" see an enemy.
2) Aimbots are basically impossible to check for on the server -- you can play a cat+mouse game (and games do) of seeing if players are consistently too accurate (or more likely, consistently too mechanical), but it's very hard, and player-side anti-cheat is part of trying to control this.
Latency is the real killer, though. A 10ms round trip + a few ms of simulation time at 144Hz will have physics objects "correct" their position after 4-5 frames have already been rendered. Bump that up to 30ms (still a perfectly common amount of latency) and you're reverting objects after 10 frames of animation.
People who play Counter-Strike with their wifi router 3 floors below them in the basement under a pile of laundry will go on a crusade to complain as loudly and relentlessly as possible for Valve to "fix the fucking hit reg".
People have -zero- technical knowledge and get incredibly angry that they died to someone they didn't even see.
So far as AAA games go this is pretty rare in practice. I guess there could be some problems to solve, e.g. you'd need to be conservative because a player could appear around a corner between server ticks, or the fact that RTS games usually operate by running a shared simulation[1].
[1]: https://www.gamedeveloper.com/programming/1500-archers-on-a-...
And even if you can 100% accurately decide when to hide or show information or if you are outright just streaming the game to the players there are still cheats that you cannot detect this way because they only enhance player capabilities within what is possible for an honest human player. For instance a simple cheat can detect if another player’s head is under your crosshair and fire automatically (with a randomized delay to game anticheat systems.) Realistically cheats these days are more complicated and do way more to emulate human input. It’s not easy to conclusively tell if a player is cheating thus way or not just looking at his inputs in one game. Maybe he is just fast, maybe he has lower latency, maybe he is just pre firing at spots he knows an enemy is likely to come from. You can’t know for sure unless you know what’s actually going on on his PC and his peripherals. And if you start banning people using just statistics you will likely end up with many false positives.
At the end of the day there is no silver bullet to cheating. Even if you fully control a player’s PC there are still ways to cheat in hardware [1]. You need to find the balance between annoying too many players with your anticheat and your game getting overrun by cheaters.
[1] https://www.counter-strike.net/newsentry/6500469346429600836