It's a bit vague about what happens when you get contention and a transaction rejects. Try again immediately? Spin and try again? Wait and try again? Wait and try again with exponential backoff? All of the above, in sequence?
There are a few spots in Go where the concurrency isn't airtight, such as shared maps. This allows fixing that problem.
Your transaction might get rejected no matter how many retries you do because the memory you touch doesn't all fit in CPU cache. CPU Cache mapping is made complicated by things like 8 way set associative (slide 17) which means something that used to work with transactions might not work if memory layout changes.
Therefore, if you get a rejection, you might want to try again a couple of times, but eventually you'll need to do it some other way.
For an explanation of set associative mapping, see https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Memory/se...
This presentation is also a lot easier to understand when watching the whole talk: http://www.infoq.com/presentations/hardware-transactional-me...
What people found, if I recall correctly, was that a lot of popular software doesn't benefit much because it wasn't written to reduce data contention, and servers especially often contend on statistics and metrics counters. But the slides show ways to avoid that. Also, the most popular software was often already well optimised to reduce lock contention.
http://www.infoq.com/interviews/tene-hardware-transactional-...