Logical order of operations:
1. The join happens, creating 14 rows
2. The where clause happens. In this case it doesn't filter anything, so we still have 14 rows.
3. The update happens. Here SQL Server will not actually change a row in table b more than once. The original row will be put in DELETED, and the final values for the row will be put in INSERTED. Table a is along for the ride here. Whatever row in table a happens to be joined to the row in table b which is selected to represent the delete or insert will show in the results.
The key is that table a is NOT joined in the OUTPUT clause, but before UPDATE filters its work list to one delete and insert per row. So that filter applies to the rows from table a as well. With no definition for the filter, it's arbitrary. If some operation caused a sort on the data before the update, you might not see what you consider the "first" row.