@wareya
You're incorrect in saying that mouse/cursor input is independent of time sampling.
As an example, during regular play, say you have a one second freeze, where the game appears to be frozen and not updating graphically. During this freeze, you could move your mouse left, click shoot, and move right back to the original position.
In an incorrect input implementation (possibly what Source does), those input events would all be processed in the next frame after the freeze is over. This would internally result in your position not moving because of the left and right movements cancelling out, and your shot firing in the original position, because to the game, your cursor didn't move.
In a correct input implementation, which is what that post describes, those input events would be spread over the virtual frame updates that were delayed due to the freeze, taking into account the timestamp of the frame being processed and the timestamp of each input event. After the game catches up, this would result in your cursor moving left, shooting, and moving back to the right, no matter if any of that is displayed graphically or not.
I'm not sure what you're saying about threaded networking and how it relates to this.