The point of Lamport's paper is that time in distributed systems is a partial ordering, not a total ordering. If you are taking values from hardware clocks, you are using a total ordering.
I thought relativity says there genuinely isn't (but it's close enough we can fudge it...)
Let me stop you right there. If you have a highly distributed system, it's design CAN NOT rely on perfectly synchronized clocks among it's components. That's actually the point of the Lamport paper you cited as well as the OP. I actually started writing a detailed rehash of the Lamport's paper but I realize I'd do a poor job of it at best. Instead, I think it's best to just point to excellent and highly readable entire paper here: http://research.microsoft.com/en-us/um/people/lamport/pubs/t...
At a certain level of precision you have to accept that data only travels at the speed of light and there is no way to have a global ordering that shows data consistently and immediately. So you can use an easy non-immediate method like a vector clock.
But to give a practical example. On something like facebook, if you receive two comments on a post within a millisecond, how do you determine the order that they appear in the list? Each request may hit a different datacentre in the world, yet somehow the machines determine the ordering, and every request sees that ordering from then on. You can't just have a single server, because that couldn't handle the load for the entire world. These kinds of things require very strict temporal ordering, which is why time is such an important thing. This leads to the CAP theorem, and distributed systems in general.