The less concepts that a developer needs to keep in their head, the better. That is one reason why transactions are popular in SQL databases: they greatly reduce the complexity of maintaining business rules. Google’s engineers said this about Transactions when designing their Spanner DB:

We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions. - Spanner: Google’s Globally-Distributed Database

Transactions, particularly distributed transactions, have a reputation for being slow or otherwise costly. This is a myth pedalled by the joint Big NoSQL & Big Microservices lobby groups. It is usually an excuse used to explain the lack of transactions in a product in lieu of a principaled reason. The truth is, achieving real ACID semantics in a distributed system requires careful design and attention to detail¹. Martin Kleppman made this observation regarding the lack of transactions in microservices:

Every sufficiently large deployment of microservices contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of transactions. - Transactions: myths, surprises and opportunities by Martin Kleppmann

Avoiding transactions comes with increased cost of writing error-free code in terms of development time, execution time, and time spent figuring out how the hell n00bslayya47 has managed to item dupe their entire inventory and sell it on eBay, putting themselves through college. Transactions make your life easier and they’re cheaper than the alternative (ad-hoc transactions, compensating transactions). Take advantage of them whenever they’re available.

Footnotes:

• ¹ Careful design is especially required when implementing Serializable Isolation, which is the only ANSI isolation level which guarantees zero data anomalies. For background on isolation levels, read A Critique of ANSI SQL Isolation Levels.