Since most devices can crank out thousands of cycles a second as is done in non-IoT applications, I suspect it is the server side as that is where the effects are most notable… thus the settings in the sketch prime the servers settings within its limits. Although as mentioned further below, there is also a possibility of some device /library side “governing”
Since Blynk is an IoT application much is dependent on the network throughput, but there are some references to recommended limitations in the documentation.
As with the ebb and flow of any variable medium, Cloud Server, network traffic, processor load… if it works stable all the time then you got it dialed in, if it doesn’t then you don’t 
trial and error within the recommendations is you only real option to determine the best settings…
But if you really want control, then a Local Server will eliminate much of the bottleneck.
Blynk implemented some “governor” like changes early last year that help mitigate the disconnections… They never stated how, but probably by simply dropping some of the rapidly incoming signals… although I did notice a reduction of void loop() cycles in my sketches when that happened.
You can read and search for further info of this…