I think there are ways to reduce the cost of this. Some distributed systems have solved it by retreating from snapshot isolation and going back to using locks. This can improve scalability if you've got lots of transactions but they're very short and rarely touch the same data. Locking individual data elements (or partitions) doesn't require a central system that knows about all commits - each individual node can just release locks for each transaction as it completes. More generally, if you could avoid having to make a decision about whether transaction A precedes or follows transaction B unless transaction A and B actually touch the same data - an idea we already use for SSI - then you could get much better scalability. But I doubt that can be made to work without a deeper rethink of our transaction system.
Something I've seen thrown about is the idea of lazy snapshots. Using SSI-like facilities you keep track of transaction dependencies and what's changed since the last snapshot. A transaction can use an old snapshot if it doesn't touch anything changed since the snapshot was taken. If it does you acquire a new snapshot (or switch to a newer existing one) and can swap it in safely, since you know they're the same for all data the xact has touched so far.
I suspect that just replaces one expensive problem with one or more different expensive problems and is something that'd help a few workloads but hurt others. It's come up when people have asked why we take a new snapshot for every transaction but I haven't seen it explored much.