I actually tried to duplicate the example on one of my oracle instances. I had to rework the update to use a sub-select because it wouldn't just run the statement as it was. It immediately fails the update with a message about the sub-select returning more than 1 row of data. You get the same message if you try to do it as a merge statement. If I had the ability to cause SQL Server to error on this I would immediately set it to do so.
I work in a small IT department and while I am responsible for the databases, it isn't my full time job. I would sleep better knowing that a badly formed sql statement isn't going to corrupt the data.
So Oracle's got consistent behaviour between the two, by the sound of it. Good to know.
The "not your full time job" is another facet of what I hinted at regarding not realistically being expected to know every external and internal nuance of every technology that you work with when you're wearing many hats. I'm in the same boat but luckily have the luxury of other people caring more about some of my hats than I do.
The behaviour in SQL Server is quite interesting, especially when compared to [font="Courier New"]MERGE[/font], because it touches on many larger questions regarding ANSI-standard syntax (as referenced by Paul White in a typically thorough response when the article was originally posted), T-SQL-specific constructs (Paul again), and the varying opinions of SQL and general developers, devoted and accidental DBAs and everybody in between as to what should or shouldn't cause a critical error (cross joined with whether you're doing ETL or OLTP, I guess). On the assumption that Microsoft would not enforce the standard on their [font="Courier New"]UPDATE[/font] (given the scope of the change and the downvotes on the Connect item that Paul mentioned), I think configurable behaviour would be a happy medium and imagine that the issue could be (relatively) easily detected at the Stream Aggregate stage (which I assume is how [font="Courier New"]MERGE[/font] detects it).
I know it's due to a T-SQL-specific construct ([font="Courier New"]UPDATE FROM[/font]) and so somebody using it for the first time should arguably have read up on it and anticipated the behaviour, but I'd further say that a really important part of it was mentioned by Dwain back in 2013:
Often times, the duplication is much more subtle than my (noted as) contrived example.
Many other bits of behaviour like this, that continue without raising a severe error, make themselves very quickly known in some way or other. This one's pretty sly and can barrel its way through an ETL process and manifest itself as incorrect figures in a presentation before you know what's happened.