Raju, thanks for your insightful comment.
In the example I drew the article from (retaining the table names used in the post), the Event table has a surrogate primary key of its own and two non-nullable foreign keys, one to Order Line and the other to Order. It is true that the Order or Order Line can be updated, but in this case there's no reasonable business interpretation if the Event relates to two different orders (although I could see possible cases where reasonable interpretations could conceivably exist).
It also might be reasonable for there to be two different "master tables" referenced by the two foreign keys, but in this case both ultimately point to the same Order table.
Sadly, the non-null foreign keys (which I didn't mention in the post) prevent the very reasonable possibilities you raise in your second paragraph.
Many thanks for the comment!