Atomic refers to "all or nothing" or "indivisible" which means that either both parties get what they wanted or neither gets it.
It requires both users to be online at once.
Atomic transactions actually have a deep history dating back to the notion of ACID compliance with databases (See Principles of Transaction-Oriented Database Recovery [Haerder and Reuter]). Atomicity in databases is usually necessary because problems can occur if a transaction is partially approved.
An example that is typically used is a sales system for event tickets. Generally you'd have at least two fields for a seat where one corresponds to reserved and the other involves payment received. When a customer is offered tickets and attempts to purchase them, then a single atomic transaction ought to occur where the seats are both reserved and the payment received flag switches. If the payment is declined (say the credit card is declined), then you want the whole transaction to fail or else you might at the very least remove some seats from the sales queue if not give the customer free tickets.
Non-atomic transactions between chains could result in a similar concern where one party gets paid and the other doesn't.
Dan I assume you are referring to bitcoin when you say both parties have to be online concurrently? If ownership is settled at the blockchain level, then isn't it sufficient to have a smart contract that triggers based upon data from a trusted feed? I think Dr. Back has some magic planned with sidechains to permit these kinds of transactions on the bitcoin network; however, Austin and Adam have been a bit mum on the details.