You should always use types if they help. And the "less (keyboard) typing" argument applies just as well to languages that can infer types. I'd rather write Scala than Python or Clojure for example, and I'd always try to avoid joining a large project that didn't use some kind of type system... even it gives me a headache. Better than a headache from unchecked run-time errors or having to write a gazillion tests. Also, can't you usually subvert the type system if you want to?
Maybe the right place to not use types is when you don't know yet what you want your types to be. For example, in Scheme or Racket, you'd probably extend the language by creating a DSL rather than a type. But why not use the best of both worlds and use Scala or Typed Racket? Given a choice I'd rather use any of these than Python, except for trivial and one-off programs.
Rather than procedures (Scheme) or types (Haskell) being fundamental, there's also languages which take Actors as being fundamental, such as Erlang (or Go). In these languages, it may not matter how good your type system would have been, since you the concurrency primitives could be subverting it anyway. For example, channels in Go have been called the new "goto", and in the Scala Actor framework Akka, the type system might not map very well to Akka abstractions either. Tl;dr: programmers can subvert type systems, but languages can too, at which point the existing type system becomes an aberration.
One approach is to compromise between static and dynamic type systems, e.g., gradual typing, such as what Dialyzer offers you in Erlang / Elixer:
http://www.codemash.org/session_old/dialyzer-optimistic-type-checking-for-erlang-and-elixir/