I've built a game engine before, so I can answer this to some extent.
In the real world, the world's state changes all the time. In a computer, that's not possible. The computer needs time, albeit very little, to compute the next state of a game world. The game world's state obviously can't change during that time.
Whenever the computer calculates the next state of the world, we call this a "tick".
There are two main ways to tick:
Fixed timestep: Here, we define how often the computer should tick in a specific amount of time. Whenever the computer can tick, we calculate how much time passed since the last potential tick, and add that time to a so-called "accumulator". Once the accumulator is large enough, we let the computer tick and remove the appropriate amount of time from the accumulator. For example, if we want the computer to tick 60 times per second, we'll wait until the accumulator has grown to at least 1/60 of a second (16.666 ms), and remove that amount of time from the accumulator.
Variable timestep: Here, the computer ticks whenever it can.
Fortunately, calculating the next state of the world is easy, regardless of how we tick. If you think of time as a "turn", then a character that moves 1 tile per turn will have moved 5 tiles after 5 turns, and 0.1 tiles after 0.1 turns.
But while the variable timestep may seem superior at first glance, it's actually much harder to deal with when you need consistent behavior. Consider the following illustrations taken from How to make your game run at 60fps by Tyler Glaiel:
Above, we have a jump simulated at a fixed timestep. No matter how fast or slow your PC is, it will always simulate this same jump the same way. Here, the foot approaches the box from above, resulting in the character landing on top of it. The same is not true for variable timesteps, as the illustration below shows:
Here, the computer wasn't fast enough to simulate every "step" of the jump, and so the foot approaches the box from its side. This means the character collides with the box and will land next to it instead.
If two players make the exact same move, you obviously don't want two different outcomes. This is why simulations that affect gameplay are usually done with fixed timesteps.
So I'm curious about exactly what is a "sub-tick" rate
The way I understand it, it's a partial tick that happens right before a regular tick.
Without this feature, whenever a player shoots, the shot will be resolved in the next tick: The world's state will advance by a fixed timestep, and the shot will be resolved to see if it hits. Between the time of the shot and the time of the next update, the enemy player may have moved enough to avoid the shot. As a result, a shot that should've hit will have missed instead.
If I were to implement this feature, I would attach a timestamp to the shot. This would allow the server to calculate the position of the players at the moment of the shot, to see if it hits. Once the sub-tick is over, the server would perform its regular tick, updating the position of the players among other things.
The sub-tick should not change the world's state beyond "something was hit by the shot", otherwise the simulation could become inconsistent. For example, a player somewhere could succeed in a jump that should've normally failed.
Is this going to affect the servers, are they going to need a full overhaul, or everything can be done with a improved code logic?
One way or another, this is definitely going to affect the servers.
Even if Valve wants to leave the current server software untouched, the sub-tick feature alone will require an update. The servers will need to perform partial ticks before regular ones.
A feature like that could require a full overhaul, but doesn't have to. It will most likely affect at least one core components of the software, however.
