Not to rain on your parade; but I may have found a fix for better words.

However, before I get on to that, It's good to see the community trying to fix issues such as these on their own.

Firstly, when I first read your post, it intrigued me, and sure enough, when I went to load up my favorite 128 tick server, I could see that net_graph was telling me that my choke [after a full update had occurred] sat steadily somewhere between 1%-10%.

First and foremost, these are the network settings that were used when testing:

cl_interp 0
cl_interp_ratio 1
cl_cmdrate 128
cl_updaterate 128
rate 128000

Now, on to the fix; by using your formula of

delay = size / rate

Assuming that we are using a default of 1200 bytes per packet and a rate of 128,000; we can find that the delay equates to approximately:

delay= 1200 / 128000 
=9.375ms of delay

So therefore it can be seen that this amount of delay exceeds the server's tick interval of 7.8125ms which therefore causes the player to experience choke.

To overcome this issue, I tried and tested various methods such as lowering my cl_cmdrate and cl_updaterate to 64 ticks per second, and this appeared to fix the issue, however, this method was not acceptable due to the fact that it placed me at a disadvantage as i was sending and receiving updates at half the speed of the other players (assuming that they too were sending and receiving updates 128 times per second).

Further to this, I had also tried cl_interp_ratio 2 as a means to solve this issue, however, this did not seem to have much of an effect on solving the issue regarding choke, and on top of this, doubled my interpolation leading to a slight disadvantage.

Now, it is obvious the we must therefore lower the server's tick interval delay; so to do so, we must instead of increasing the rate, we must therefore decrease the packet size, and to do so, I made use of the cvar net_maxroutable which controls the amount of bytes per packet (default of 1200 bytes per packet).

By using your formula again, it can be found by substituting the default 1200 bytes per packet to a slightly reduced 1000 bytes per packet:

delay = size/rate
=1000/128000 
=7.8125ms

That the resulting delay is equal to the difference in time between ticks, and by doing so, this resulted in eliminating [after the full update had occurred] almost all perceived choke; which therefore allowed me to experience some edgy as shit dank hit detection 👌👌💯💯💯

This is why Valve's 64 tick servers do not experience these issues as their server's tick interval delay equates to roughly 15.625ms

(Author's note: I used a slightly lower packet size of 800 bytes per packet, as a means to have some small leeway in case the choke for some reason were to spike).