This is an obvious exaggeration; if you ignore the golden path, the code doesn't solve the problem it's meant to solve. But yes; writing reliable code is all about the edge cases. Eliminate them if you can; code for them if you can't.
Does anybody know the study in question? (I have never seen another study on the topic. Does anyone else know of one?)
This was almost certainly either done in assembly or PL/I or Algol or something. Do more modern languages change it? Exceptions? Dual-track programming (options or Maybes)?
Regardless of exact numbers, yes, error cases are something you have to think about all the time.
Snark aside, I am somebody who is very concerned about edge cases, but those ratios seem completely wrong to me for the kind of code I write. And perhaps one should say "corner cases" instead of "error cases". Corner cases aren't necessarily errors. What I find is that a good algorithm that is properly "in tune" with the problem space will often implicitly handle corner cases correctly. While an algorithm that was hacked together by somebody who is "coding to the test" without really understanding the problem space tends to not handle corner cases, and then the developer tries to handle them by adding if-statements to patch their handling.
In the end, devoting 70% or 80% of thinking time to corner cases seems entirely plausible to me. 70% or 80% of lines of code dedicated to corner cases may be a smell.