Honestly this is all largely a completely solved problem space. The article is just way out in left field seemingly fully oblivious to how game netcode currently works, which certainly isn't with AI prediction.
But tldr is the only thing a client ever predicts is their own inputs, which of course can't really ever end up wrong later on. There's no other prediction happening (eg, the position of other players is not predicted)
And then for anti-cheat/optimization purposes the server also only sends positions for enemies that could be visible soon, which is done by taping into the same map chunking logic that would be used for asset streaming.
But you'll find they all largely do the same basic thing. There's nuance in some of the rules and what state is replicated and what isn't (such as server side or client side ragdolls), but the general architecture tends to be the same. And without a fundamental shift in connectivity, seems pretty unlikely to change.
I had worked on a number of commercial MMO games' server and I don't necessarily agree on your opinion on "a completely solved problem space". Have you worked with your game designers and artist to find a sweet spot across latency, bandwidth, security, hit box and effect synchronization etc... just for one type of action skill? I had. It ended up with a very customized protocol which was nearly unusable on any other stuffs. It might seem simple to do such things for one or two features, but it's actually death by thousand cuts; it doesn't take that long till all those state synchronization and replication codes invade through game-play and presentation layers and all the logic and you got hundreds of them now.
And I am not very sure if you had a good look through the resources that you posted... Many of them are pretty explicit on their use of own ad-hoc solutions and the trade off that had to be made, which really supports my arguments. (Yeah, I think I already have read and watched more than half of them over the last decade) And this is not surprising if you have a good theoretical ground on distributed systems which have literally hundreds of impossibility theorems and real time games usually have quite tight latency constraints.
Look at actual game engine docs like this one from Valve https://developer.valvesoftware.com/wiki/Latency_Compensatin... or this one from Halo https://www.halowaypoint.com/news/closer-look-halo-infinite-...
But tldr is the only thing a client ever predicts is their own inputs, which of course can't really ever end up wrong later on. There's no other prediction happening (eg, the position of other players is not predicted)
And then for anti-cheat/optimization purposes the server also only sends positions for enemies that could be visible soon, which is done by taping into the same map chunking logic that would be used for asset streaming.
There's a ton of other great resources on this topic here https://github.com/ThusWroteNomad/GameNetworkingResources
But you'll find they all largely do the same basic thing. There's nuance in some of the rules and what state is replicated and what isn't (such as server side or client side ragdolls), but the general architecture tends to be the same. And without a fundamental shift in connectivity, seems pretty unlikely to change.