The way to identity a table row is the primary key, and you can use that here if both tables have the same primary key.
If the primary keys are automatically generated and different, use another unique constraint. After all, there should be a way to relate rows between those two tables.
As mentioned by @PaulWhite in his answer, the "quirky update" method is undocumented and can be unreliable. It requires careful coding, and checking the execution plan to ensure everything works correctly.
And you can quite clearly see, from the execution plan you have now provided, that he was right: there are four threads:
The documentation for the UPDATE statement says (emphasis added):
Variable names can be used in UPDATE statements to show the old and new values affected, but this should be used only when the UPDATE statement affects a single record.
Some people have tried to make this "quirky update" technique work reliably for multiple rows by applying ever-...