This seems like a potentially interesting article with a very poor title. None of the 6 lessons cited seem to have anything to do with why the lander's anchoring mechanism failed to deploy.
(At least, that's my reading of the brief quotes from the original report; so much of the context has been removed or aggressively summarized that it's hard to be sure what they're talking about.)
The "developer's confession" part seems to insinuate that a software problem was to blame, but nowhere in the article is that actually stated.
Not only that, not enough time was spent on detailing the sensors and systems used to implement fail over, why sometimes there were fail over components while for other systems there was a single point of failure. Would be nice to have a reasoning why some components had redundancy while others not.
The anchoring system was insane to begin with and would likely not have worked even if all these alleged software and computer problems had not occurred.
When you are a lighweigg tlander in a very low gravity of a comet, the last thing you need to be doing is shooting harpoons at the icy ground. The harpoons are not going to stick well/at all and the very act of firing them is going to send you careening off back into space.
The anchoring mechanism was designed over a decade before the lander arrived at its destination. The prevaling theory was that it would encounter a relatively hard and compact layer under a thin dust cover. Then the Deep Impact mission happened while Philae was already in flight and showed that theory to be false. Hindsight is 20/20.
He is responding to the title, which was not written by the people who designed the spacecraft.
The referenced scientific article is titled "A Comet Revisited: Lessons Learned from Philae's Landing". It deals with more mistakes than just the crash.
So he is not even in contradiction with the experts.
CRC was used to prevent misinterpretation of commands. Not authentication of commands. Cryptography would also need a CRC-type component (MAC code or AEAD cipher used correctly).
That's what I was referring to with cryptographic checks, MAC/AEAD/signatures/keyed hash/etc, or just a secure many-bits-long hash like sha2(Was that still secure at the time they built it?).
The op only mentioned cryptographic checks, not signed and encrypted. Even then, the signature and encryption algorithms used are important and you should still have a MAC to detect alteration of the cipher text. Hence my AEAD suggestion.
Given the nature of the comms- to a device in the expanse of space- securing the transmission from malicious users seems like the last thing they should worry about. It’s more the accidental corruption of data, hence something like a CRC or simple MAC are sufficient for the circumstances. Why waste energy and CPU cycles on something you don’t actually need?
(At least, that's my reading of the brief quotes from the original report; so much of the context has been removed or aggressively summarized that it's hard to be sure what they're talking about.)
The "developer's confession" part seems to insinuate that a software problem was to blame, but nowhere in the article is that actually stated.