I suspect you are taking my comment as a personal insult rather than reading it for the meaning I intended. The point I was trying to make is that the skill involved here was hiding the lines in a large source tree and hiding the history. The actual lines of code are unremarkable, absurdly incorrect when taken in isolation, and not where the clever part of this attack lies. The author of the article is stating it as something else.
See also my reply to cbr where I make essentially your same point: the way to get this past a code review is make it part of a large diff.
It's not so much a personal insult as the common tendency most people have to base decisions on best rather than average performance. This essentially devolves to the Deming/TQM/Toyota/etc. school of management where you focus on making the system tolerate human error rather than hoping your humans consistently perform well.
That said, I do disagree that this is easily detected – I would bet that a significant percentage of C developers would not notice this if it wasn't mentioned in the context of a security problem. Linux kernel developers are [hopefully] well above average but … there's a reason why so many style guidelines feature this one prominently and it's not because few people have made this mistake.
It's easy to thump your chest and assume that you're smarter than those developers (which is almost certainly wrong) but that misses the underlying lesson that humans will make mistakes and the likelihood goes up with the complexity of the task. That can be switching to a language which bans problematic behaviour, automatic use of linters and other tools, rigorous code reviews, etc. but in each case you're making environment safer rather than trying to find perfect developers.