I don't think it's too long for a blog post, but if you do then why not break it up into a series?
ACID does not require locks. You can use timestamps, for instance. It's also wrong to say that locking "achieves" ACID transactions, since locks (or some form of concurrency control) is only applicable to the I in ACID.
You mention the blocking nature of transactions, but don't say why it exists. It's not to do with locking, but that is the inference.
Unfortunately whilst the strict 2PC protocol guarantees atomicity, no transaction manager actually implement that otherwise we'd have transactions that don't (can't) complete. Hence heuristics.
In general I think there are too many generalities in the text so far, such as "In a compensation-based transaction, changes are visible outside of the transaction as soon as they are made." That's only true for certain compensation transaction models, not all. And they don't guarantee an atomic outcome any more than ACID transaction managers do.