Transactions are a fundamental abstraction in dependable computing systems. Put simply, a transaction is a unit of work which either succeeds completely or fails without leaving any side effects. To illustrate, a commonly cited example of a transaction use-case is where an amount of money is to be moved between bank accounts. In this case the goal is to ensure that the money both leaves the sender's account and is received by the recipient's account, or if something fails, for it to appear as if the transaction itself logically never occurred.
This is the inherent value of transactional systems; if something goes wrong, they allow us as programmers to make it appear as if it never happened in the first place. In an inherently unreliable world, transactions can truly be a godsend, especially when we consider the amount of computing infrastructure involved in something apparently as simple as moving money between accounts. Any aspect of that computing system from the network cables through to the software and everything in between has a small yet significant chance of failing something we'd rather it didn't do while it's processing our money! The point is that using transactions to safeguard against failures allows us to reverse any partial work performed during a failed transaction and, thus, prevent our money from disappearing into a banking black hole.