Why - read but not update ops fail in case of lacking space in tempdb database?

Question

MSDN online article "Choosing Row Versioning-based Isolation Levels" states:

• "tempdb must have enough disk space for the version store. If there are very long-running transactions, all the versions generated by update transactions during the time must be kept in tempdb. If tempdb runs out of space, update operations do not fail, but read operations using row versioning might fail"

Can you explain me why?
taking into account that (quoting the same article):

• "When either the READ_COMMITTED_SNAPSHOT or ALLOW_SNAPSHOT_ISOLATION database options are ON, update and delete transactions for a particular database must maintain row versions even when there are no transactions using a row versioning-based isolation level... Because the record versions are stored in tempdb"

that is, update (but not read) operations require space for row versioning should have IMO failed due to lack of space.
And why do read ops fail if they do not require version storage in tempdb ?

Answer 1

^{(Converting my comment to an answer. I don't know if this is definitive, but it makes sense to me. If you can prove it wrong, let me know in the comments.)}

The row versions aren't actually required to complete a write operation; they're only required by readers that come along and need those versions of the rows. If they need them.

If tempdb runs out of space during version generation, while that's not okay, it may end up working out if no readers need those versions. A read operation would only fail if it needs a version of a row that isn't in tempdb.

Furthermore, any write operation is considered more important than a SELECT, for obvious reasons (same idea as when the Deadlock Monitor figures out which process to kill if there's a deadlock), so it's preferable to fail a SELECT if possible.