If I didn't know it could fail, I wouldn't check for an error in its return code.
Usually when I write code, I assume it's my job to ensure the code works as designed in all reasonable circumstances. That requires understanding the failure modes of any external code I'm calling, at least as far as if/how it could fail.
IIUC, your approach is more like what I'd call prototyping. I.e., you accept that the code might be wrong, but you prefer to deal with that if/when it comes up in testing, so that you can move faster up-front.
Is that how you reason about it?
My suspicion (and naive hope) is that most people would not ignore that case if they knew it was dangerous. But I would expect them to ignore it if they didn't know it existed. Hence this article, I guess, which serves to remind everyone that it can in fact happen and is quite dangerous (due to a potential later interaction with kill).