Okay, but as far as I can tell he changed the algorithm (recursive c++, pop/push to global array, etc) ... doesn't that kind of negate the argument unless you change it in the assembly version as well?
1) High level languages are easier to refactor and maintain than lower level languages (changing the algorithm in the assembly's a big job).
2) For performance, the algorithm used is almost always more important than the language you choose to implement it in.
Both of those points back up the author's assertion, it's a shame he didn't specifically discuss them.
I used to hand-code assembly (or generate it, eg "compiled bitmaps") back in the 8086 days. For many situations there were easy gains to be had that couldn't be achieved so easily in high level languages. These days I wouldn't dream of attempting it other than perhaps for vector code in an inner loop. I'd far rather spend the time profiling and optimising the algorithms and data structures because that's where the big gains are going to be. To go ahead and implement something in assembly when the algorithm clearly isn't yet optimal is perhaps fun but also kinda insane.