recap of this lecture: wrap locks into an API with a hardware twist?

I don't think it's quite "wrap locks" (there's a bit more nuance). Transactions relax the implicit assumptions you make when you use a lock, and provide an alternative, more flexible abstraction you can work with. When you use a lock, you implicitly assume that everything in the critical section can only be touched by one thread at a time. A transaction requires that the reads/writes inside a transaction do not "interact" with other, uncommitted transactions.

You can, of course, implement this using locks, but they are not necessarily required.