The likelihood of the system crash is bigger in the durations of hours and days than in seconds. That's why data inside LongRunning transaction persisted to disk. That's why the orchestration data used in the Long- Running transaction must be serializable. That's why the LongRunning transaction theoretically slower than Atomic transaction.
Note: Atomic transaction in BizTalk is not atomic in strict sense. It can include requests to the external processes, calls to the .NET classes, etc. Each of these processes could change something outside the orchestration and the transaction Rollback does not automatically roll back all these changes. It would be dangerous.
The Atomic transaction is short by definition. It cannot nest other transactions inside. The Atomic transaction is processed as a single unit of work. If Exception is fired inside the Atomic transaction, all we have to do is to roll back this transaction. And BizTalk makes this automatically. We cannot change this roll back process no matter what sort of Exception was fired.
The main difference between the Atomic and LongRunning transactions in BizTalk, how they behave in case of the internal Exception. Atomic transaction always automatically performs Rollback. We cannot avoid this Rollback and cannot do something else. LongRunning transaction could catch the Exception in the optional Exception block and process additional rollback operations in specific custom code. But the Exception block cannot prevent the automatic Rollback. The Rollback occurs after executing the Exception block. If a LongRunning transaction does not have the Exception blocks it processes an Exception the same way as an Atomic transaction.