All signals will travel the same speed in your cable. Often around two thirds of the speed of light in vacuum.

Next thing is how fast we can transfer information, which is affected almost completely on the baudrate. Implementing a 100Mbit/s or gbit ethernet in the clocks would be more expensive. And would require repeaters if the cable length is too long - RS-422/RS-485 can manage much longer cable stretches depending on used baudrate. Ethernet on the other hand can't be set for an arbitrary baudrate.

The "magic" with NTP isn't the baudrate of the speed the signals travels in the cable. The "magic" is that NTP uses timestamps in both questions and answers, and an algorithm where you can subtract most of the delay times from the latencies in a network. Remember that when using NTP, you may have very many jumps between the client and the time server. Maybe 10 jumps or more - and every jump adds a random jitter to the latency, depending on how fast the machine is, and how loaded it is, and what priorities the TCP/IP stack is using. With a single link using RS-485 or RS-422, you always have a fixed delay, that you can compute from the length of the time message and the baudrate you use. So no need for the NTP calculations. If the server sends the time in ms resolution, and the transfer time of a message is 120 ms, then the client can (remember that the client just has to know the baudrate or it wouldn't be able to communicate) just add 120ms to the received time and get a time that is pretty much identical to the server-side time. Or the server could always add 120ms before the transmission.

There are almost always many different ways to skin a cat. It's just that different solutions are best at solving different specific problems. When you don't need NTP, you don't gain anything from using NTP.