> In your example, User A doesn’t get to make his deposit-it just fails. Does he have to manually retry later?

That’s right. The first thing you want to do is to prevent inconsistency in the data. We want User A to fail because he was working on a stale copy of the data and was about to commit an error.

> it is hard to see the advantage of the optimistic approach

The main benefit we found in the optimistic approach is that it is simpler to implement and it does not lock. Imagine you need to performe a remote API call in the middle of your method (send an ivoice for example) — in the pessimistic approach the row will be locked for the duration of the remote call (which might take a while).