The distinction is that in a pure FP language, Autrijus' emminently clever code would not be possible.
That is not correct at all. All programs exist to generate side-effects; otherwise they will be indistinguishable from no-ops that take lots of time to run. This is true for all programming languages of all times, FP or not.
The distinction that a pure FP language makes, is merely that pure functions and side-effectful actions are separated, because the former is always inlinable and memoizable, and the latter always executed sequentially. In contrast, in a language that does not make this distinction, both are executed in some arbitary order.
In other words, functions never have side-effects, but a program does. In Haskell and other pure FP languages, you can write functions that defines composable actions, and group them under the main function. The action defined by main will then be executed as the program itself.
Personally, if I was to implement a fair shuffle in real-world situations, I also would choose Perl instead of Haskell, since it would save me some time, to the order of one minute versus ten minutes. But if memory use (or, sometimes, speed) is of critical importance, as often demanded in my paying work, then GHC is a much more elegant alternative than GCC to me. Which is why I'm working on Inline::GHC after all...
Also, I have no doubt that Perl 6, as compiled by Pugs to Parrot, can be even more efficient than GHC here. :-)