Let's say we have SELECT t.tid, u.uid, x, y, z FROM t INNER JOIN u ON t.tid=u.uid, and we try to determine if the result table of this SELECT will support UPDATE.
Without 1, either tid or uid are allowed to repeat, so the result table of SELECT can contain records with duplicate values of these fields, so you cannot update the result table using those fields as key - because when you want to say "please set X in this record to 5", you cannot use tid or uid to identify the record, they identify more than one record.
Without 2, eg, with tid and uid having unique indexes, but not being referenced in the join condition, the result table again can contain records with duplicate values of these fields. (The criteria here is more complex than "you have to use all fields in an index", you have to use enough fields for the join to be 1:1. Eg, if t has an index on region+country and u has an index on region, a join on t.region=u.region keeps things 1:1 and so the result table will stay writable even though t.country does not participate in the join condition.)
Without 3, the result table lacks data to identify records in the original tables.
I am not sure about "filtered" in 4, but yes, the relation has to be 1:1, 1:N/N:1/M:N all make the result table non-updatable because writes create ambiguities (this goes past just having record values potentially being written to multiple times with no good way to specify which of the writes should win - if you take record X in the result table and say "OK, I am going to allow writes to it even though this will change multiple records in the original tables" the effect of this write is that fine, you changed multiple records *and this changed* records in the result table that you didn't write to, this backfires in many optimizations).