Why are clients being sent that extra data in the first place? The server should track players and only push the information each player should have to that player's client. No need to hand every player the locations of other players when they're across the map and behind several walls.
Even with no extra data at all, at a certain point they're going to run into the analog hole. Cheaters will be able to point a camera at their screen and have it connected to their mouse/keyboard (real or not) so they can send inputs with speeds beyond what a human is capable of. Maybe it's not feasible to stop every cheater on Earth and the whole concept is incurably broken. There's always the option of letting people host their own servers to play with friends and other people they trust to play the game fairly. It's a hell of a lot more fun to play with people you know anyway. Tournaments can be done in person on dedicated trusted hardware under direct observation.
Performance reasons, usually. Easier to draw an enemy on the screen (and figure out occlusion, etc) than have the enemy pop in from nowhere due to lag. Also prevents lag (or netspeed in the UT days) hacking (used to be a thing, not anymore).
Because FPS games don't run in lockstep. They run in server ticks, which the client interpolates or even extrapolates with prediction for smoothness. This means the server has to send player positions a bit earlier than they would be visible via strict occlusion culling.
If you tried to run FPS in lockstep it's atrocious. This is literally why John Carmack originally implemented client side prediction for QuakeWorld. Do you think he was just too stupid to do the obvious simple correct thing? Or maybe the problem is actually a bit more complicated?
Again, hnews is anchoring on aimbots when that's by far the least interesting way to cheat.
No, but both hardware and software have changed dramatically since the 1990s. We even have cloud gaming services that run games remotely with very little being done on local hardware. They do currently over-promise when it comes to performance, but it's not unthinkable that we're at (or soon will be at) a point where games don't have to depend as much on the random PC at the player's end of the connection even though that's the way things have always been done.
Latency is the obvious one - you have to be able to tell not only if a client can see another client, but whether they might be able to see each other in, say, 500ms. That's pretty hard and computationally intensive, at-least compared to just checking whether bounding boxes have line-of-sight.
Where things get interesting is when we come to emergent behavior tied to rendering. A good example is shadows - you can have no LOS to a player, and not be in a position where you could get LOS quickly, but be able to see their shadow. So your client needs to know where the other player is so the shadow can be rendered correctly. Sound is also hard, and forces you to balance server load and client trust. Lets say someone really far away takes a step that's audible within 10m. You can't hear that, but the server would have to check distance against every player to confirm that. If you have a directional sound system (where sounds from inside a room will originate from the doorway for those outside) it's even harder, as the server is having to calculate the shortest path not blocked by the enviroment. Even if you do all this, you're still screwed - since when you determine the dishonest player can hear something so you tell their client client to play a sound, you have to send them the coordinates of the origin, so you're telling them where the other player is anyways!
- Server-side actor occlusion.
- Server-side physics with client-side prediction that's been in use since 1996.