Judging by what we know of the kinds of errors that they're talking about having be uncatchable, I think you might be overstating the worry a bit. Sounds like the list is constrained to failures that really do mean a bug in the code such that something is seriously wrong, let's get the heck out of here is probably the only appropriate response if you're trying to build a robust system.

Take the null reference example: A NullReferenceException means that a value's null in a spot where the programmer either didn't believe or didn't consider that null would be a possible value at that point in the program. So when it happens, there are two things you can be sure of: First, things have strayed off into the weeds. Second, there's nobody around to check everything out and make sure we can get steered safely back on track, because the developer's been out of the picture since the start of compile time. These two facts imply that letting execution continue would be A Roll of the Dice, and therefore Not a Good Idea.

If having the module crash in this situation isn't acceptable, no worries. There are still ways around it short of splitting the component in two. One much easier option would be:

  if (x == null) { /* handle null case */ }