In distributed databases that offer transaction semantics, they need timestamps to order transactions that take place. A tighter synchronization of clocks mean they can execute transactions faster because they can reduce the amount of time they wait (based on the potential clock drift between machines in the data center)

Wouldn’t it be better to put the effort towards designing a system that doesn’t need precise timekeeping?

See https://cloud.google.com/spanner/docs/true-time-external-con...

It should explain how clock uncertainty relates to throughput of causally-related transactions.

If you know that your clocks are exactly the same in New York and Japan you can assume that if an account creation timestamp in Japan is before the account creation time in New York for the same username that the account should go to the Japan user and the New York user will be told that he cannot use that username. Previously the way to handle that problem was to have all account creation be done on one server which will block the table while it is doing writes. That doesn't scale when you need to insert millions of rows a second.

When you have collisions, the timestamp might be the thing that decides which update came first. The higher the precision of the time stamp, the faster you can run stuff.

PTP is required in a number of 5G implementations. Facebook's 5G core (Magma - https://github.com/magma/magma) utilizes it quite a bit.