I don't think performance is the primary reason behind this. The motivation section in the article states in the very first sentence:
Silent property failures and the resulting proliferation of 'undefined' are the most prominent mistake in JavaScript, and can be rather tedious to debug (very much like null pointer exceptions in other languages, but much more common).
Having different objects (that were created in the same way and represent the same thing) potentially have different properties at different parts of their lifetime can easily lead to a codebase where you can never be certain of anything about such objects and have to do loads of explicit checking every time you use them. Especially in a larger codebase developed by more than one person.
It's a nice feature for whipping up some quick prototypes though.
It's not just for quick prototypes though, many times for me it's about marking up objects from other libraries with my own data. I'm extending them one off and not changing the base behavior in any way, this should cause no issues to anyone else using that object. Yes that can be done with inheritance in say C# so long as the base object isn't sealed, which many library classes are from MS especially, ugh.
The undefined issue seems no different to the null reference as you mentioned. I run into it constantly in C#, in fact everyone does that why they are adding the null lifting operator (?.), javascript could do the same for both undefined and null.
I may be weird but I actually like the fact that javascript has both undefined and null. It allows an extra state over just null in C# which I constantly wish I had, typically for things like data/domain objects. With undefined and null it's trivial to encoded the fact that a property is not loaded say from a db or sent from a client vs it being loaded but the value is null or sent over the network with a null value.
Silent property failures and the resulting proliferation of 'undefined' are the most prominent mistake in JavaScript, and can be rather tedious to debug (very much like null pointer exceptions in other languages, but much more common).
Having different objects (that were created in the same way and represent the same thing) potentially have different properties at different parts of their lifetime can easily lead to a codebase where you can never be certain of anything about such objects and have to do loads of explicit checking every time you use them. Especially in a larger codebase developed by more than one person.
It's a nice feature for whipping up some quick prototypes though.