Your example question highlights why this is called "OPTIMISTIC" locking. It's not perfect, but if suffices for a large number of situations in the real world AND it uses much less resources (including time) than a hard lock.
When using this type of locking, you're trading for performance, and often improved use-ability, betting that your transactions will just work the majority of the time, and you're assured that in those cases where it doesn't work you'll be notified (exception will be thrown) and you can then step back and "do the right thing": try again, abandon, ... however you choose to handle the exception.
The pessimistic lock may be very inappropriate for high-performance transactional system where you need some level of locking, but the probability of them colliding is minimal: how many of the millions of users of xTunes (name changed to protect the innocent..) "order" (update) at any moment, and how many are all ordering (updating) from the same account?