I just perform physics-based dead reckoning, but with players it's different because a player could have released a movement key or started holding down a different one, which should cause a different outcome in their movement. I don't include the time a keypress started or ended in an update, so the accuracy is limited by the resolution of the updates, but it's sufficient for the purposes of my game at 15hz (67 msec).
In my game the local player's input is applied to their entity by the same code that applies the last-known input for all other players to their own entities as received from the server (along with their positions/velocities). The reason for this is because I just use the physics simulation to predict everything, and if the next update received has a new position for an entity that is different than what the physics has simulated locally then the client just interpolates across the error until the next update is expected to arrive.
Velocities are snapped to whatever is received from the server, but the difference between current position and received position is added to the entity's position along with its velocity over the period that elapses between updates being received, unless the difference is a few meters, then it just snaps the position as well. This means that clients are always simulating one update behind the server. EDIT: This is because one update arrives and it takes until the next one arrives before everything has interpolated to the corrected position, at which point the new update arrives and the whole system has to play 'catch-up' again... over and over...
This, ontop of a buffering delay that is used to smooth out network update jitter (updates arriving at irregular intervals), and the latency between client/server leaves clients with a minimum of 50+ msec delay between what's happening on the server and what they're actually seeing.
What that article is talking about is the fact that you can't just magically know which direction a player has chosen to move, or jump, or crouch, etc.. and you just have to wait until that information arrives because players are unpredictable. The best you can do is know what keys they were last holding, and generate the player movement for that particular input state, and hope for the best.