Are read-only transactions handled without contention? I understand that a read-write transaction needs to be aborted if a later conflicting write is committed. But read-only transactions can view a snapshot of what was committed before they begin - you trade a little bit of latency for being conflict free. It doesn't even have to be the default as long as you offer it as an option, you might want this if you know you are reading hot keys, or as a fallback if you've been aborted X times.
This was IMO the big innovation of true time in spanner - contention free reads at either now, or at some time in the past.
Yes, if your timestamp is far enough in the past (this is determined by the maximum clock offset configured for the cluster), and if you don't collide with writes of a long-running transaction (which may run at a timestamp that could influence what you read), you will not have to worry about contention. What you're suggesting are definitely options for reading consistent, if slightly out of date, information from a hot keyspace.
There's a blog post on time travel queries, which conveniently expose the required functionality as specified by the SQL standard.
This was IMO the big innovation of true time in spanner - contention free reads at either now, or at some time in the past.