I think the point he's trying to make is that in the general case, boring code is safe (boring in the eyes of someone reviewing your code, that is). That's not to say boring code is better. Remember the fast inverse square root gem (http://en.wikipedia.org/wiki/Fast_inverse_square_root)? Definitely not boring, but optimal in the situation that it was in.
That's definitely not boring, and also awesome. Like I said, sometimes you find a clever hack. But if I saw that code in a code review, it would be a huge red flag for me. I'd want to see a pretty good justification for using it instead of a more standard algorithm. (It happens to be in this case that there IS a good justification).
The key problem with inverse square root is the risk of having that code unmoored from a very well put together comment explaining the rationale for it, and perhaps a TODO in the backlog about re-evaluating when to get rid of it.
Without knowing that it's a fast inverse square root approximation using the Newton-Rhapson method with 1 iteration using some clever bit twiddling hacks and an initial guess chosen by experiment to be optimally efficient in terms of accuracy and especially for speed you can end up with a lot of problems. First, someone could look at it and spend a lot of time trying to figure out what it was doing before realizing what it did. Second, it could cause people to attempt to replace it without realizing the value of it, causing wasted effort. Third, it could cause people to try to improve it, spending time attempting to find a more optimal first guess, or adjusting the bit twiddling nature in some way. Fourth, and worst of all, it could develop a reputation as a bit of "deep magic" which shouldn't be touched because nobody knows exactly how it works, so nobody ever re-evaluates whether it's worth keeping. As it stands now it's obsolete code given that modern GPUs will perform the relevant calculation in hardware much faster.
Granted, in this specific case a lot of these problems are much diminished (since the company was small, the code and its rationale was well-known by the dev lead, and it's reasonably straightforward to reverse engineer the operation and rationale for the code with some investigation), however this might not be the case somewhere else with some other piece of comparatively magical code.
When you write a bit of WTF code that's actually worthwhile imagine that everyone that worked on the code is now dead and researchers are studying it, what information would those researchers want the most? Now put that in a comment.
P.S. Also, god help you if you happen to be lucky enough to have a chunk of poorly documented "deep magic" code that happens to have a defect in it.
Even the article essentially admits that there are many cases where what is normally seen as boring is actually dangerous - just he redefines these cases as "not boring".
Specifically, repetitious code is the most obvious case of boring and that's not at all safe. He just redefines that as "not boring" because it raises red flags for him. But that's pretty strained reasoning to say the least.
Code that is almost repetitious can also be dangerous because spotting where the changes are can be hard and the repeated parts can lull you into comfort.
Of course, code normally shouldn't be too interesting either but that's a different question.
It seems like it boils down to something like a boring code review indicates safe code because everything that's interesting at that point is a problem.
