This is all true, but his actual point is that exception handling should not involve Data.Typeable (or any type casting) at all. I do feel this is an extremely obscure point that does not justify this hyperbole, but it is his blog and he is free to decide what is important there.
From his post, it appears that ML handles exceptions by allowing code to add new constructors to the 'exc' type at run-time. This is effectively indistinguishable from the GHC implementation of dynamic typing, which uses typeclasses.
Without some sort of dynamic type casting as used in ML or Haskell, then it's not possible to implement an exception handler that can extract information (such as type) about an exception. All you'd be able to determine is "some exception was thrown".
Yes, ML is adding new constructors to exn type at runtime, but this is different from GHC implementation of dynamic typing which uses typeclasses, because GHC does not add typeclasses at runtime. Take a look at ezyang(who is a GHC developer)'s comments in the post.
I repeat that this is extremely obscure and probably only interesting to people like ezyang. He is engaged in the discussion, so I guess the post was not pointless.
He somewhat obscures that point with tangentially-relevant grumbling and dead-horse-beating, if indeed that's the point he was trying to make (I guess I can see it, looking at the submission again with that interpretation in mind) -- you've made it more clearly in a paragraph than he did in a whole blog post.
Actually, as far as I'm aware, IO exceptions don't see much use in practice -- they aren't considered very "Haskell-y". In fact, that's partly because of the dynamic typing aspect that this whole discussion centres around; but also because their behaviour is dependent on evaluation order, and because the possibility of an expression throwing one isn't encoded in that expression's type. None of that is really in the spirit of idiomatic Haskell.
As such, MonadError is the way exception-like behaviour tends to be handled, AFAIK.
