Point Y is in fact, not true. unsafePerformIO is not part of Haskell, the language. It is an additional feature provided by GHC. (Similarly, the typeof keyword and statement-exprs are not part of C, but extensions provided by GCC.) Interesting Haskell programs can and usually are written entirely without use of unsafePerformIO.
This is, however, a fairly minor technical point. More importantly, I feel that the division the article's author makes between two definitions of functional programming is misleading. "Functional programming", just like "object orientation" and "imperative programming" and "logic programming" and "structured programming" and every other "paradigm", is not a term with one or even two well-understood clearly separated definitions; it is a term for a grab-bag of features, tendencies, and patterns of programming languages. The world of FP isn't divided into people who think that only absolutely pure languages should be used and people who think that any language with first-class functions is okay; it's a continuum. The author just happens to be further towards the "anything goes" end of the spectrum than the authors of the articles he is replying to.
unsafePerformIO is part of the the Haskell 98 Foreign Function Interface, which is "An Addendum to the Haskell 98 Report". (See chapter 5 Marshalling <http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html...) All haskell compilers support the foreign function interface, and it will be a required part of the next haskell standard.
Use of unsafePerformIO (or any other unsafe function) should rarely be needed in real world programs though.
This is, however, a fairly minor technical point. More importantly, I feel that the division the article's author makes between two definitions of functional programming is misleading. "Functional programming", just like "object orientation" and "imperative programming" and "logic programming" and "structured programming" and every other "paradigm", is not a term with one or even two well-understood clearly separated definitions; it is a term for a grab-bag of features, tendencies, and patterns of programming languages. The world of FP isn't divided into people who think that only absolutely pure languages should be used and people who think that any language with first-class functions is okay; it's a continuum. The author just happens to be further towards the "anything goes" end of the spectrum than the authors of the articles he is replying to.