I'm sorry, but did you even read the article? The exploit is explicitly stated, it's trusting unauthenticated client state. That's a fundamental design flaw in the intended behaviour, not an accidental coding error. They gave the profile ID to reset to the client when serving the page, and then blindly used whatever profile ID the client sent when submitting the form. The fix was to fetch the profile ID for the authenticated user instead of sending a profile ID on a round-trip through the client.

I certainly agree that the problem wasn't the technology here, but I disagree with your conclusion. "some if missing somewhere" is far easier to avoid technologically than a high-level design flaw like this. It's fairly easy for a type system to notice that not all cases in a conditional are accounted for, but it's much harder for a type system to understand that it's inappropriate to use client-submitted data as a profile ID for a password reset request (as opposed to operations like submitting a friend request, where it's perfectly valid).