The net result is code which breaks in spectacular fashion when the first unexpected condition is met.

Which is generally what you want to have happen. Failing fast is a good thing. If your code does anything other than "stop executing" after encountering an exceptional situation, it should be very something carefully considered and well-thought-out. With checked exceptions, the "I'm in a hurry to get this working" version of the code often ends up looking a lot like:

  try {...}
  catch(ExceptionType ex){ //TODO figure out what to do here }
  ... keep going ...

The danger is what happens in that "... keep going ..." section - the code is working under faulty assumptions and that can lead to a lot of non-obvious but horrific bugs. In the unchecked "I'm in a hurry" version, the program simply crashes at that point.

So I think the C# design choice leads to the least pain under bad conditions. I'd rather have a fragile application than one just robust enough to write bad data to my database.

That said, it's not perfect. Any sufficiently lazy/stupid programmer can write the equivalent of "On Error Resume Next" in any language.