In "Transactions are your friend," Mark Little discusses how transactions provide the knowledge that your interactions with data are valid and your dataset is healthy, along with some of the common perceptions around transactions, such as "transactions" being the same as two-phase commit and others.
... "everything I do is within a single VM, so I don't need transactions". This is definitely an education issue, where distributed transactions have become synonymous in the minds of many people with transactions. Most people can see that if they're accessing resources/participants across physically distinct machines or processes, there's a need for transactions to coordinate simultaneous updates to state. In a local (single VM) environment, the need is often overlooked. But it is still there: in many cases, even within the same VM, applications use and modify data from multiple different sources, and in that case, you need the benefits that transaction processing provides. Distribution just makes it more obvious that independent failures can cause problems. But they're still there in the local case; you may just have to look a little harder.
... think of transactions like an insurance policy: compared to how much time, money and effort you may lose by not using them, the cost of using them may be well worth it. Obviously there's a tiping point on any graph of cost of using transactions versus advantage they may bring, and that point is going to be very dependent on your application. But consider it nonetheless.