The point of the monitoring is not to get the best possible score. The point of the monitoring is to assess a server as best as can be done from the point of view of local clients, or at least an approximation of that. As such, a monitor half-way around the world is of little use, even if it is good, because it does not reflect, in general, what local clients would see. Sure, if a far-away monitor scores a server well, then it is likely that also local clients may get good service. But even that is not a given, depending on the local and regional networking.
E.g., a server may be sitting in a datacenter close to an IXP with good international connectivity, so score well with far-away monitors. But maybe a lot of clients are with providers that do not connect well to that IXP. E.g., Deutsche Telekom in Germany has been accused of not providing good connectivity with some other national providers because DTAG does not connect to open IXPs, but is asking money from other providers to connect to them. And if another provider doesn’t pay up, packets take a detour and/or cross underprovisioned and overloaded interconnects, raising the likelihood for packet drops, path asymmetries, and higher jitter.
So despite the good score from a far-away monitor, local clients might still not get good service. A local monitor has a better chance of reflecting that. And even more so in the inverse case, i.e., some far away monitors scoring badly, but local clients getting excellent service.
Thus, the system makes heavy use of the RTT when selecting monitors, but the score itself still has the higher impact. Because it is hard to tell what the reason for a low score is, so to be on the safe side and not kick out servers that actually perform well but where some monitors may have issues, the score gets precedence when selecting monitors. And because of the gaming factor for operators, i.e., a low score is rather demotivating, as is being raised in one way or another time and time again - see the original topic of this thread for example. So having a good score overall, and many good scores at the top of the monitor list, is important motivation for server operators.
Then, in general, every NTP client makes heavy use of the RTT, in the form of the root delay. Sure, a high RTT does not automatically and always mean bad connectivity (aka packet losss), or asymmetry and jitter. But as has been pointed out time and time again, most recently by @avij in his last post above, the chances of something going wrong just increase with the distance/RTT. Not sure why you don’t get that, and that that is one reason why the pool prefers to serve clients from local servers, i.e. currently from within the same country zone. Where the current country zones are a simplification for the system, similar to what @avij highlights, because in many cases, peers in the same country are close to each other - though not always, and being in a different country also doesn’t mean there necessarily is a large distance. But as a quick and especially simple approximation. And the plans to loosen the current strict zone concept will still try to honor that. Just as NTP clients typically prefer upstreams with lower root delay, i.e., lower RTTs between the upstream servers, because it simply reduces the likelihood of issues, and makes for a lower bound on the maximal path asymmetry that can happen. Not sure why you still don’t get that.
And lastly, NTP clients also typically prefer samples with lower RTT over samples from about the same time but with higher RTT, because the assumption is those will typically have lower path asymmetries. Again, not always, but as a rule of thumb, and for simplification, because there is no good way to measure actual path asymmetry in a strict and anonymous client-server relationship. That is what @ask has been explaining above with respect to the system picking the sample with the lowest RTT - just as a typical NTP client would.
