I'm only not surprised because of the very poor state of software assurance in the industry as a whole. Indeed, the issue is not OpenSSL specific, similar bugs have been made elsewhere (and I assume also carried forward in "more audited" OpenSSL forks).

But thats the only reason I'm not surprised. Cryptographic code is safety/security critical and as an implementer (In my experience) the potential for this kind of error is very clear. This class of mistake can be found with a strong testing and verification strategy: it can be found with correctly targeted randomized tests (as was the case for this CVE), it can be found via manual review, or it can be found via formal methods.

Widely deployed, high value cryptographic code should be using all these techniques and producing publicly visible evidence of their use.

Of course, serious software issues aren't just cryptographic ones. Systems programming, as an industry needs to up its game. (And the common tropes of higher level languages to save everything is countered by examples like this: Software safety and correctness is more than memory safety. Higher level tools can be useful, but if they get in the way of really rigorous reasoning about the software they may be counter-productive.)