Stadia (and similar) can render entire games server-side and then deliver them to you for a nominal fee. I'm certain that in 2021, we can hook up a nvidia gpu to the server and allow some basics physics calculations run for ~128 players.
If we can't, there 100% is a market for a chip, card, server, etc. that can do this. There is an entire group of gamers (30's+ with kids and demanding job, not a lot of time) who are sick and tired of FPS cheats and just want to relax and play a game for an hour a night. They would happily pay for a non-cheating version of a game.
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!
For example, in Fortnite, if you toggle a lagswitch (as in, block Fortnite UDP for some time), then reconnecting to the server will return you to the same position you were at when you disconnected, assuming you were just trying to run on the ground. However, if you toggle a lagswitch in a vehicle, the servers don't want to do expensive, complicated physics server-sided, so your client becomes authoritative to your position and the sanity checks are simply making sure you're not teleporting around large chunks of the map in seconds. If you were to hack your client and give your vehicle moon gravity, the server generally wouldn't care about that.