Ah, I think I see where you are confused -- your arguments seem to make more sense when dealing with a single, local database. The idea here is that you want to achieve atomicity, but you need to do it across multiple distributed databases and you want to have a system who's components have exactly the same time in order to ensure consistence across each database.
Attempting to extend the landlord example... let's say that I'm your landlord and you have to pay me £1000 each month. You send the bank a message telling the to pay me the money. The bank may make several copies of that message and keep it around for their own reasons. Now, let's say that there are employees at that bank whose job it is to do go through all copies of all messages and make sure what they say is done. If they find a message from several months ago saying "transfer £1000 from you to me this month" and are somehow oblivious to which month it is, they may transfer an additional one thousand pounds even if it's already happened. It's not an exact analogy, but...
WalMart cannot commit if someone else committed previously, they have to try again.
Atomicity is precisely what it is. There is no fuzziness there, you either do it or you don't.
The problem with current database designs is the idea of BeginTransaction, that function is the core of the problem.
"Transactions" in the real world are NOT completed until everyone agrees.
Consider you yourself enter into a transaction with your landlord, you BeginTransaction..
However during the negotiation you choose to disagree and back away from the deal.
That transaction, even though it took three months to decide was rejected (by either party).
The only "transaction" is the committed transaction.