Dude, Clojure isn't even purely functional, nor is it meant to be. I respect Rich Hickey a lot too, but that doesn't mean he's some kind of god who blesses functional things. In reality, Haskell is much more at the forefront of functional programming than Clojure is — it actually embraces FP down to its core, purity and curried functions and all, while Clojure takes the more pragmatic stance of maintaining easy Java interop. Haskell's whole purpose is to push the boundaries of functional programming, while Clojure's purpose is to be a very useful modern Lisp that separates value and identity. Clojure is a really nice language and IMO more practical than Haskell in general, but it is not the last word on FP.
The most common and impactful source of problems or bugs are ones of misconception, not TypeErrors, therefore anything that lets you iterate faster or get something out the door quicker is desirable. (I heard him say something to that effect in a talk)
He must have a typechecker in his head ;). My experience with learning Clojure (knowing Haskell) is that I constantly bumped into bugs where I thought "Haskell's type checker would have caught this".
Usually, when I write new functions in Haskell, I write down the type signatures first. This helps catching many errors. For instance, if your type signature is:
f :: Integral n => [a] -> n
You can not accidentally apply a function (in f) to f's argument that assumes a list of lists, or return something that is not an integral number.
This cuts both ways: strongly encoding semantics using the type system catches many potential bugs in functions, but it also provides guarantees to the caller of a function. For instance, I know for sure that f does not return a 0/nil/None pointer, I know that the number is exact (since it is integral), etc.
