Because it’s simpler to just query pool.ntp.org than to figure out which zone would be appropriate for a given controller.
Also, it’s more robust; if a zone were taken out by an attack, the controller would still eventually pull the correct time.
First order, latency doesn’t degrade accuracy because the delays in each direction are very closely matched.
Just for laughs, I tried:
# ntpdate -q us.pool.ntp.org
server 64.225.34.103, stratum 2, offset -0.008044, delay 0.03348
server 68.233.45.146, stratum 2, offset -0.002144, delay 0.07866
server 45.33.31.34, stratum 2, offset -0.000468, delay 0.06360
server 198.98.58.17, stratum 3, offset -0.004388, delay 0.09660
27 Dec 11:03:08 ntpdate[15876]: adjust time server 64.225.34.103 offset -0.008044 sec
# ntpdate -q europe.pool.ntp.org
server 147.78.228.41, stratum 2, offset -0.002064, delay 0.18588
server 185.111.204.220, stratum 2, offset 0.000933, delay 0.17934
server 79.133.44.137, stratum 1, offset 0.002737, delay 0.17409
server 94.198.159.11, stratum 2, offset 0.000045, delay 0.18059
27 Dec 11:03:44 ntpdate[15998]: adjust time server 79.133.44.137 offset 0.002737 sec
The European servers were actually somewhat closer to my system clock.
But in any case, given Rachio’s job, a time offset of even a second or two would not be an issue. Accurate time is mostly useful for debugging, when you need to compare activities in controller, app and back end.