I asked Peter Norvig, who was on the review board, and he gave me the following more nuanced answer (the question was asked in the context of type-safety in programming language choice):
The problem involved reading data from a file and a miscommunication about what the numbers in the file were. I don't know of any language, no matter how type-strict, that forces you to tag the string "123.45" in a file with the units of force (newtons vs foot-pounds), nor do I know of any language, no matter how type-loose, in which you could not impose such a convention if you wanted to.
Beyond the initial error, the reasons why the error proved fatal were more around organizational structure than around language choice:
(1) An anomaly was detected early on, but was not entered into an official issue-tracking database. Better practices would force all such things to be tracked.
(2) The team was separated between JPL in California and Lockheed-Martin in Colorado, so there were no lunch-time discussions about "hey, did you get that anomaly straighten out? No? Well, let's look into it more carefully..."
(3) The faulty code was not carefully code-reviewed, because of improper code re-use. On the previous mission, this file was just a log file, not used during flight operations, and so was not subject to careful scrutiny. In MCO, the file and surrounding code was re-used, but then at some point they promoted it to be a part of actual navigation, and unfortunately nobody went back and subjected the relevant code to careful review.
(4) Bad onboarding process of new engineers: The faulty code was written by a new engineer -- first week (or maybe first month or so -- on the job. This was deemed ok because originally it was "just a log file", not mission-critical.
(Personal communication 2011-06-14)