What @kozlovsky said :) Only advice I would add, is SELECT .. FOR UPDATE doesn't (and shouldn't) use MVCC, so it guarantees you the most recent version of the row.

In my comment I said the use case for this feature is not typical, but I can list the case:

If you needed to read the most recent value, apply logic (external to the DB) and then write back a new value you will likely want serializable to prevent lost-updates.

A hypothetical (but poor example) might be a stats counter where you read the value, add one, then save it back.

Without locks lost updates are possible because default isolation level is not SERIALIZABLE

As I replied to your comment further down, you (and the article) are confusing the implementation's use of locks to ensure atomicity and isolation with the applications use of locks to ensure consistency. These things are different.