Where network replication matters a lot more though is on things like movement and shooting in competitive games. There is a great short series of blog posts by Gabriel Gambetta that covers different problems and solutions, but everything is a tradeoff https://www.gabrielgambetta.com/client-server-game-architect...
One thing it doesn't mention, but that I thought of and implemented a protection against, is a malicious client sitting there and listening to game states, then send a bunch of inputs with timestamps in the past that would put the player into an advantageous position. I eliminated this by coding the server to reject any inputs that are older than 500 ms, and since the server was authoritative, the client had to just deal with it and put the player where it was up to 500 ms ago. The server would even tell the client "You are lagging and I ignored your input" when this happened, so legit clients could deal with it.
While yes, this could create a negative player experience as a player who is dealing with a lot of latency or packet loss would frequently get teleported back, that player would already be having a negative experience due to everyone else jumping around. Even with interpolation between predicted states and authoritative states, at 500 ms latency, you're going to have a bad time in a real-time multiplayer game when latency matters.
If doors synchronize closer than a player's sniper rifle range then a player can either stand just behind a door (that is open for them) and shoot people at range (who see the door as closed). Or the door defaults to open and a closed door that seems like cover allows you to get sniped.
While the ideal is to synchronize everything at the same distance, if you have 100+ players on a single map and a sniper rifle with 500m range you can be synchronizing the stage of hundreds of doors per player and eating bandwidth that would (usually) be better used synchronizing player position state. In practice you end up doing some amount of 'automatic' synchronization and some based on context... and a server that has the definitive world state that can 'undo' shots through closed doors etc.
Building rendering distances can also be an issue with doors, generally you switch to simpler building models as they get further from the player's camera. But you can't include doors in the lower level of detail models until you are at a distance that enemy players are also not visible. So while a building can be a 200 triangle shell at 400m it still has to have doorways and network synchronized doors, even if the doorway is 4 on-screen pixels it should still be possible to see a player move behind that open doorway (or not see them if the door is closed).
Half of games networking is finding out what you can "get away with" from an impact/user perception. Ex: play hit effects, sounds in a de-synched way locally but have major game events be authoritatively acked by the server, the local events also do a good job of masking the latency. The other half is really cool tricks like dead-reckoning or lock-step[1] which uses a completely deterministic game state to sync hundreds of entities over latent connections.
It's a really fun design space that's leverages heavily both the game design(designs where players "predict" are easier to keep in sync/fun), a level of deception to hide latency and cool technical approaches to hard problems in a non-deterministic environment.
Desync is common and is caused by packet loss in UDP games. It's not usually worth while to compare your state with the authoritative state, because that requires a round-trip from client->server. Instead, the server can rank each piece of the state as important (has been altered recently is a good measure of importance), and just spam out a bunch of redundant game state packets hoping some of them arrive.
You can build a guaranteed delivery packet system on top of UDP, but a guarantee has to come from the client meaning you're waiting on round-trips to confirm that the states are fully in-sync. Most games (especially fast paced shooters) don't need this level of assurance, and heavy packet loss over a long period of time should just result in a disconnect for that player.
Each game packet is typically packed (and compressed) with other game packets to maximize bandwidth and acknowledgment data for the reliable packets is also compressed into the data stream. Reliable packets take very little additional bandwidth (assuming your UDP connection is not going to lose many packets in normal use). Players will pull ethernet cables for a second to force packet loss if the unreliable packets give them an advantage (ie to allow them to interpolate through a wall or to not register shot hits).