He argues that developers are generally too stupid and lazy to use exceptions correctly (which may be true), but if they instead are forced to use manual error code checking (which achieves the same, but requires typing lots of tedious and fragile boilerplate code) - they would do it diligently and correctly.
I didn't really think that that was his core argument. From my reading, he was saying this:
1) Exceptions that arise from a bug should just assert
2) Exceptions that arise from an expected 'exceptional' are actually part of the true logic of the program, and shouldn't be shunted off into a catch/rescue block, because that increases the temptation to consider these as being some how subordinate to the 'happy case'.
3) The fact that exceptions are easy to propagate up the stack means that they can break encapsulation, and it becomes easy for lazy programmers to not treat special cases correctly.
Of course, I may be completely wrong about that, but I just thought I'd share what I had understood, as it's apparently different to your interpretation.
I agree with you interpretation, I just don't agree with the logic that if developers are too lazy to handle exceptions, they will do the alternative (checking and handling return values) correctly, since it is just as easy to ignore an error code return value than it is to ignore an exceptions.
And if we agree that lazy developers might not handle every error, the "default case" with ignoring exception (the exception propagates to the top and kills the program) is much preferable than the default case without: the program state becomes corrupted, but the program keeps running.
Another point: Exceptions are not for cases which can be handled as part of the normal flow. Rather they are for exceptional cases which requires you to break out of the current context and handle the error on a higher level. So if you use exceptions correctly they don't break encapsulation, rather they help encapsulation since you can handle errors at the appropriate level.
I'm not sure I buy that.