The problem is that leading the shot has two side effects: 1. what you shoot at in game isn't what you're hitting on the server, (you shot a player, but dirt kicked up from the ground several feet in front of them) and 2. some gameplay mechanics rely on accurate replication.
If you throw a grenade at a player and "lead the shot" maybe it sticks to them on the server. It kills them.
But on your side, it missed because you personally lag compensated, stuck to a vehicle, and now the vehicle blew up instead and flew off a cliff.
Now the game sends back updated entity positions and the vehicle and its occupants are back on the ground and everything just snapped for you.
You can rewind game state and make it not visible to players, then run hit calculations and do things like kill players and destroy objects without snapping.
Proper lag compensation implementations make it such that infrequently do you actually notice lag, even in exceptionally poor connection environments.
With rollback if you guess they are going to continue moving in the same direction you just aim right on where you see them because of the prediction. If you think they are moving in the other direction you need to guess when they started moving in the other direction. That we are using rollback networking can't get rid of the need for you to guess this. To make that guess you'd like to know how far back they could have changed direction so you have some time interval in which to guess. From your perspective that time interval is based on the difference in time between the server's state now and the last server state you received. But my point is doesn't rollback make it impossible for you to know that while playing the game.
Whether you're using rollback or not you as the player need to know intuitively what is the time difference between the server's state and the latest server state received.
The side effect is that if anything of importance gameplay-wise did occur back in time, this abstract lag compensation function would reset just enough game state to make a difference.
In other games, the abstract lag compensation function might need to be something else, but for most purposes, I assume moving entities or actors back in spacetime is adequate. After the lag compensation function and game logic has completed, you call a second function, the inverse abstract lag compensation function. This is the equivalent, or should be, of the opposite operations performed in the first function. So, in this default case, moving all entities or actors back to where they were.
You wouldn't want to replay sounds for example, because you don't want to do anything that gets perceived by players, but the general idea is that lag compensation itself is "invisible" to players.
That is to say, if an enemy is moving on your screen in California, no matter how fast they're traveling, if you shot them from Phoenix or New York City, and sent that input back to the server in San Francisco, it should be calculated as damage applied, regardless of latency, up to a maximum latency tolerance such that players are not able to abuse lag compensation up to some upper temporal limit within reason.
For reference, the Source 1 stores player positions for up to a second.
If a player drops packets for a while, they shouldn’t be teleported to a position once they start sending packets again. They’re sending input not positions.
When I say lag compensation removes latency-based leading-the-shot scenarios, I mean it, full stop. It’s completely removes this problem.
You’re describing teleporting which is caused by other malimplemented player movement and networking code.
With no rollback code then I feel the lag and can properly make decisions based on not only what I see right now but the exact amount of lag I'm feeling. How I play the game should be adjusted based on the latency of the lag. With rollback that feedback of the latency is hidden.