Uh, no... if you look at the quote, I was talking about "ModifiedBY" columns, which typically have a variable width datatype. If EndDate is based on a fixed width temporal datatype (datetime, date, datetime2()), then you won't have expansive updates because of a null changing to a value in such columns.
I DO, however, recommend that EndDate not be NULL for other reasons and they're the same reasons why they are never null in Temporal Tables (for example). IMHO, EndDate should always be "9999", which resolves to 01 Jan 9999 so that you don't have to test for both NULL and some future date in your queries. The reason why I don't use 12/31/9999 23:59:59.9999999 like MS does for their temporal tables is because that leaves no room for some other "tricks of the trade" on such columns whereas 01/01/9999 does. It's also easier to type "9999" than "12/31/9999 23:59:59.9999999"
This is typically a price history table. But you still include the actual price charged at time of sale in the order for historical purposes. You must be absolutely sure you have the correct price for credits, for one thing. Sometimes the salesman/manager can reduce a price, either to close to sale, as an offer to make up for something bad that happened with the customer, etc.. If after such a situation they can return an item, you want to be certain you never credit them more than what they actually paid.
I admit I didn't see the ERD you're referring to, I missed it. So I'll need to review this q further to comment on that.