One thing that deep, static type systems often lend themselves to is complex types, and those complex types lead to complicated designs; and if I have the option, I'd rather spend my time designing a simple architecture than exhaustively testing and validating a complicated one.

Since using clojure (roughly the last 3 years in data-pipeline style architecture) I try to follow a principle of writing functions that do just one thing, simply, and do it well, keeping the interface as basic as possible. Almost all of the time when writing clojure, I'm writing functions that act on a couple of built-in types and return one built-in type, usually the same one as before.

Additionally, I try to isolate side effects.

Following these principes, I find that even when I'm dealing with a stinker of a namespace or running into a runtime error, it's pretty cheap to try it out in the REPL and get to refactoring.

That said, I kind of want my cake and to eat it too. I do miss static types -- just not as much as I missed them when I was writing Javascript or Ruby. If I write a new clojure library now, yes, I would try to instrument it (at least the public api) with clojure-spec. If I could re-design clojure, I'd leave out null and maybe build a more intuitive interface to clojure-spec to use it as a kind of progressive validation system via annotations and type hints.