Because readers in PostgreSQL do not lock data, regardless of transaction isolation level, data read by one transaction can be overwritten by another concurrent transaction. In other words, if a row is returned by a SELECT query it does not mean that the row still exists at the time it is returned (which would be sometime after the current transaction began); the row might have been modified or deleted by an already-committed transaction that was committed after this one started. Even if the row is still valid "now", it could be changed or deleted before the current transaction does a commit or rollback.
Another way to think about it is that each transaction sees a snapshot of the database contents, and concurrently executing transactions may very well see different snapshots. So the whole concept of "now" is somewhat suspect anyway. This is not normally a big problem if the client applications are isolated from each other, but if the clients can communicate via channels outside the database then serious conflicts may occur.
To ensure the current existence of a row and protect it against concurrent updates, you must use SELECT FOR UPDATE or an appropriate LOCK TABLE statement. (SELECT FOR UPDATE locks just the returned rows against concurrent updates, while LOCK TABLE protects the whole table.) You should take this into account when porting applications to PostgreSQL from other environments.