The issue of functional programming languages as being more productive is heavily debatable to say the least. Productivity isn't, by far, the result of a source line count. That's usually the first mistake these folks make. Anyways, he's sort of right when you consider some languages do offer similar constructs to functional programming. That's clearly the case of C#. He felt frustrated because he couldn't (or thought he couldn't) reduce source by trying to employ similar logic to Haskell. In addition, his efforts ended up making him write bad C# code. Hence why he jokes about Haskel and Python having made him a worse programmer. As others pointed out, he could have written better code. Even when he was writing that article in 2006 he would have known that, had he payed any attention to the then under-development LINQ.
Certainly I expect him to be right on other situations where the functional-like constructs in C# (mostly, LINQ or any type implementing IEnumerable) will still not suffice comparatively with Haskell. But he is alone in his frustration. If he plans to bring into an imperative language some manner of functional programming I don't see anyone wanting to follow him. One of the most important aspects of learning different programming languages (and even more important when learning different paradigms) is to know to separate the waters and keep every language and its paradigms to themselves.