HOLY (removed)
So they've managed to take the absolute worst parts of lockstep deterministic simulation, none of the benefits, and slap it into client-authoritative netcode. AMAZING
First off, this is explicitly a visual delay on remote clients that they're referring to, which is better than lockstep determinism in the sense that the player shouldn't have a local input delay, but worse because we already have the most up to date data for other clients but it's just not being used because they never designed their state and animation systems with networking in mind.
In a lockstep deterministic simulation such as in Age of Empires 2, Supreme Commander, etc., there is a similiar built in delay to all input. This is so that the input can be replicated over the network to everyone else's simulation - so long as no one has a connection latency of > 250ms (or whatever the delay is), it works great.
Since those simulations are deterministic, if someone is cheating and sending bad input, it will desync the game because the cheater's units did 10k damage or whatever when everyone else's client thinks it did the correct amount of 500. The simulation state is hashed and compared each frame to check this.
It's a tradeoff - it's a really good architecture for RTS because then you don't have to sync anything at all except player input, instead of 1000s of unit states, but comes at the cost of that added latency and reducing the simulation's max speed to that of the slowest machine in the session.
Artificially introducing an input delay is probably the worst thing you can do for playability in a twitch based game, and they're not even getting the benefits that come from lockstep determinism.
And to top it all off, it's client-side authoritative in TYOOL2k19, which we already knew because Star Marine was hacked to a hilarious degree within days of its release. Something that wouldn't be possible if they were actually taking advantage of that delay. Instead, they just introduced it as a band-aid solution to their horrible netcode.
All of the problems that they need to solve are described in this documentation:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
They can be used with OCS or whatever their fancy buzzwords are; there is absolutely zero reason to avoid the industry standard best practices and cook up whatever it is that they're doing, because it's going to be worse.