Say you’re driving a car in a straight line, there’s very good odds that in .25 seconds you’ll still be going straight so your predicted line will be very close to the real line. With players you can’t guarantee that, they could zig zag, turn around, jump, etc much more likely to change and require prediction reconciliation.
Pretty much every real game map is going to have hills or elevation changes. You're really never driving in a straight line.
Straightforward extrapolation as with dead reckoning does poorly with both cases.
Then once you’ve mastered the art of getting cars not looking wonky you have to deal with collisions between them when they’re moving at speeds where typical gameplay latencies make it easy for discrepancies between clients to cause mispredictions which result in complete misses or large interpenetrations that physics engines have a bad time with.
That CoD video explains what you do instead with the client buffering segment. You show other clients in the past even from the point of view of the latest data you received so you can interpolate so get no discontinuities at the expense of a slightly wrong view of the universe. Your client is one round trip ahead and the other clients are one round trip plus whatever delay behind. Which is where things like peekers advantage come from.
Similarly they state exactly what I’ve said that extrapolation ends up making the game unplayable and again a input buffer on the server is the solution. The concern there is how much you buffer as it impacts latency quite heavily. So their system is dynamic based on the quality of the client connection.
Note also in this case that extrapolation is only done in the server which is not responsible for the visual result and is done based on client input data which is usually sent at a much higher rate than the server sends state about other players back. Consequently the visual discontinuities will be hidden by the interpolation on the clients and will be small as mispredictions are expected to be caught quickly and the players are relatively speaking slow moving. It’s interesting they still need to stop extrapolating and fall back on buffering in the worst case.
The reason determinism is needed is that the client is only sending their input so in order to work out where they are from only that information it must play back deterministically on both client and server. The same series of inputs must result in the same movement otherwise they’d end up in different positions. It’s also very useful because you can then rollback and replay movement if a missed input frame arrives.
Rather than demonstrating your point it refutes it pretty handily and is a pretty good lay explanation of the considerations when writing networked gameplay systems. Believe it or not this has been my bread and butter for the past sixteen years!