For instance our site in Germany was more than 15ms away by fiber from DE-CIX stuff in Frankfurt. The site in Singapore had better latency to any cdn or hosting operation that was in Singapore itself, but much worse if traffic had to find its way through the terrestrial submarine fiber internet to other places. End to end latency between Afghanistan-germany-seattle or Afghanistan-singapore-seattle was considerably different.
Yes, the position of the two end point sites on the sphere that is the earth will have slightly different speed of light times to a satellite in geostationary orbit. But 99% of that latency in the above 490ms figure is the extreme distance of the satellite, and not whether or not one site is slightly further down the sphere, as viewed from a theoretical observer sitting on the satellite.
It is also worth noting that modern scpc/mcpc modems can be intentionally configured to use more computationally "expensive" FECs, in a trade off of slightly more bps/Hz squeezed into a given sized slice of transport kHz, at the expense of a few ms higher latency. This is a network engineering design decision made when a link is first brought online. Modern modems and ASICs, FPGAs have made this less difficult than it used to be. If I can use an analogy for software developers, this is sort of like the speed vs file size trade off choice made between using gzip, bzip2, xzip, at different settings and compression levels.
Path length varies from ~34500km to ~42000km (~115ms to ~140ms). So, assuming an ideally placed teleport, from 115 * 4 = 460ms to 115 * 2 + 140 * 2 = 510ms speed of light delay on round trips. This is why I said I found 492ms to be an amazingly over-precise number. Just call it 500ms. :P
Note that may be true for one bird in Afghanistan, but the path length isn't exactly the same everywhere, nor are the delays of all modulaiton schemes.