Using my setup as an example. I have a hard wired gigabit connection between the telescope and the computers here in the house. The processor at the telescope itself is relatively low power, but with very high network thruput. If I do a latency evaluation on the overall system, the latency between camera and processor at the remote location is the highest in the system overall, the cameras connect with usb. The delays of getting an image out of the camera are measured in microseconds, then again in microseconds transferring that image over the network. This is bordering on insignificant compared the 1 or 2 seconds used to make an exposure.
A few years ago, I wrote a guiding application where I originally focussed on latency and high speed guide reactions, the results were not what I was hoping for, so I started to do some math on the results with detailed logging at every step in the process. The conclusion from that exercise, seeing artifacts were the most significant source of very short period errors, and an extremely low latency system that responded with absolute corrections would just chase seeing artifacts, and ultimately it was over-correcting far to much, far to often. There were two ways to deal with that, and I tested both of them. The first method was to run a rather complex real-time statistical solution which did a rudimentary evaluation of seeing artifacts on the fly, then correct errors that fell outside of the seeing statistics. The second method, was to just increase the exposure times on the guider images so that seeing artifacts start to show up as 'larger stars' on the guider image. Both methods ended up producing essentially the same end result, with a small bias toward the high speed statistical solution.
I went a little farther, and tried to measure ways and means of dealing with seeing artifacts. To do that, I chose a bright star pair that can be resolved on very short exposures, alcor and mizar in my case. I took a series of very short exposures (0.05 seconds) over a period of a minute. Camera download time did not allow me to daisy chain them entirely back to back, I was getting about 1.5 images per second. I analyzed the centroid of both stars in all of the images, then compared the distance on that centroid pair. The conclusion from that exercise, there is a variation between those two centroids that ends up as a measure of the seeing artifacts. Then using the same set of images, if we were to be guiding perfectly on the image of one star, how would it affect the image of the other star on the same plate. The answer was, with 2 arcsecond seeing, and perfect guiding on alcor, the mizar image bloats by close to 2 arcseconds.
Final conclusion of the exercise, our equipment is not sufficient to guide 'inside seeing', to do that I would need a camera that can deliver frames at the 1khz range of frame rates, and be sensative enough to resolve the guide star at that rate. Then, the rest of the system needs to be responsive enough to react, and make mount movements on the order of 1/4 arcsecond per step at the 1khz rate. Not going to happen with a guiding system built around doing mount movements for guide adjustments, and even the currently available tip/tilt systems sold as active optics to the amateur astronomy market are not capable of making that large of an adjustment on that time scale.
So, once we resign ourselves to guiding outside of the seeing artifacts, then re-evaluate latency, conclusion is, the latency of a gigabit network connection is really insignificant compared to other latencies in the system, the largest of which is exposure time on the guider plate. If you use the example of a 1 second exposure on the guider frame, then your guide data is already 1/2 second old before you start to extract it from the camera. The time frame for extracting and delivering the image over a gigabit network is measureable and possibly significant, but still compares to that half second in terms of orders of magnitude smaller.
The other part of the equation, is the mount. I measured the PE on my EQ6-Pro very carefully. It has a 22 arcsecond peak to peak error curve over a full cycle, but at no point in that cycle does it move at a rate higher than 2 arcseconds per second. In our area, 2 arcsecond seeing is almost unheard of, and typical is more like 4 or more, so on the extremely short term, it's impossible to detect the difference between a seeing artifact, and a mount excursion. So, my final conclusion on the numbers from that part of the exercise, unless my mount has excursions that are greater than the seeing in the time and distance domains, then extremely rapid guide responses dont really help with image quality.
Years ago, I often used to wonder about folks that use 5 second exposures for autoguiding, originally I thought that was kind of pointless. But today, I know, it just depends on the quality of the mount. If you have a very good mount that does not have PE discrepancies that are greater than typical seeing artifacts, then latency is not such a big deal, what matters is that you apply corrections on a timeframe that address the PE of your mount. If your mount has only 1/2 arcsecond of PE over a 5 second period, and you are imaging under 3 arcsecond seeing, then 5 second guide exposurs are fine, and allow you to guide on much dimmer stars.
We have two physical limiting factors in our systems here today. First is the sensativity of the guider optics, there is a minimum exposure time required to properly resolve the guide stars. The second is the time it takes for the mount corrections to show up at the mount. Both of these items are measured in terms of large fractions of a second. If your guide rate is 1/2 sidereal, then its roughly 7.5 arcseconds per second. A 2 arcsecond adjustment takes 1/3 of a second to complete. The other factors in the system, time it takes to analyze the image, and time for image transfers. With those times measured in milliseconds, they tend to get lost in the noise level of the other measurements. It would be a whole different story if you are doing this process over a low speed network connection, I dont think I'd be happy with the system if my guiding data was being transferred over a wifi link. But in our case, it's all done over a gigabit hardwire connection, so latencies are 3 orders of magnitude smaller than they would be over wifi.
And, just as an example to show, I recently ran hardwire to the all-sky camera, it has been on a wifi link for the last couple of years. On the wifi link, pulling a full frame uncompressed via the indi subsystem took over a second for the image to transfer, it it takes longer to transfer over the network than it does to extract it from the camera. Today, the bottleneck is data speed on the usb link extracting the image from the camera, and it delivers over the network in a very small fraction of that time.
As we plan out the equipment for the new observatory, in this whole equation, one thing stands out in my mind. Extreme high speed guiding may be useful for a mount with large and rapid PE excursions, but, if the mount itself is that poor in tracking, then it's very likely it has other issues as well, so guiding alone is not all it needs to get the desired result. The most likely culprit is slop in the gear meshing of the mount drive system such that, first gust of wind that hit's the telescope will give you a multiple arcsecond excursion over a very short period of time, and since it's gear slop, no amount of fiddling on guider ports can correct anyways. There are some mount errors that just cannot be corrected, no matter how much time / effort one focusses on trying to guide it. I have an EQ3 that falls into this category. But if you are dealing with a mount that can be corrected realistically, and working under typical seeing that amateur installations have, then the latency of a gigabit network connection for guiding is NOT the limiting factor, lots of other factors are limiting long before network latency pops up above the noise levels of the other calculations. Our EQ6 and NJP both fall into this category.
