Making the libraries cope with bad programming is not good practice, but it is what keeps businesses using your software for decades. The Old New Thing really should be standard reading, because this sort of thing is barely the tip of the iceberg.
Other similar API avoidances that Microsoft have found programmers using to check things include obscure undocumented registry keys, API implementation bugs (seriously!), the padding data in tangentially related structures returned by API calls, and more
It doesn't blow up in his face; he may not even be in business any more. He's the guy who wrote the driver for the crap scanner your customers use. The only person to blame when an update makes their scanner stop working is you, the company who shipped the update.
You're right in the sense that the only person the customer will blame is oftentimes you, and there is some merit in that, and some merit in the idea that you should add dodgy hacks to your code to provide for some backward compatibility.
However, the more accommodating you are with this stuff, and the more you clutter up your code base, and the less easily-maintainable your stuff gets as a result, the less you are able to deliver later on. And while, contrary to your argument here, you actually stand a fair chance of the end user realizing it's the printer drivers that suck and not your OS, the cries of "Windows sucks now" are the fault of nobody but Microsoft.
Making the libraries cope with bad programming is not good practice, but it is what keeps businesses using your software for decades. The Old New Thing really should be standard reading, because this sort of thing is barely the tip of the iceberg.
Other similar API avoidances that Microsoft have found programmers using to check things include obscure undocumented registry keys, API implementation bugs (seriously!), the padding data in tangentially related structures returned by API calls, and more