It takes time to recognize such failures. If the clock skew is only off by a few seconds or even minutes, the impact isn't so horrible, but if the clock jumps ahead by 20 years, you've effectively prevented any writes to that key for 20 years. Even if you only consider a few days, that's long enough that it can result in lost business.
> logically nondeterministic state
timestamps should only be used to tiebreak between logically observed events. You've somehow combined a timestamp field as a tiebreaker, as client data to be stored, and as a request id. If you separate them then adjusting the timestamp as a tiebreaker (along with node and counter) will remain logically consistent.
> And it's important to zoom out and look at the actual consequences of missed writes at the application layer
Lets. You wrote a distributed data store that can lose writes under certain circumstances. If the UX impact is negligible for you, that's great. However, it may be catastrophic for another use (say storing the latest price read for a stock option). For developers to use your database, it means they need to do an impact analysis for every single use. Just wait until someone decides the API is easy enough to use that they try to put payment data in there.