I just wanted to clarify that in the event of an abort, the transaction is usually restarted. This is possible only because none of the modifications it originally made were permanent and so could be discarded in order to start from a clean and consistent state. In practice, transactions that fail repeatedly will acquire some sort of global lock in order to force itself to completion. This is true for the Blue Gene/Q implementation of hardware transactional memory:

"The solution in Blue Gene/Q is also simple: If a transaction fails more than a few times in a row, you acquire a global (per CPU) lock, which prevents any other cores from making forward progress until the starved process is finished." Source

For serializability, the transactional memory model guarantees the existence of some serial order that is consistent with the end result of running the program. This does not means that all of the transactions were actually running in serial! For instance, transactions with no read-read or read-write conflicts can run concurrently. The serial order, in this case, can order these transactions without conflicts arbitrary, as the result obtained will be the same.

In line with what @kevtan said, the serializability of transactional memory implies sequential consistency. The key thing to note is that this sequential consistency is at the granularity of entire transactions rather than individual instructions like we talked about in the memory consistency lecture.