That's basically the consensus among professional academics on the matter. Also among well respected programmers in senior roles like Joshua Bloch and John Carmack.
The problem is static typing is applicable to only a subset of any particular programming task (in other words, even a Haskell or ML program that compiles is not necessarily guaranteed to be correct, insofar as it still may not produce the output desired by the programmer.)
Because of this, it introduces incidental complexity into a program, because it subdivides the programming task into a part that can be addressed via static typing and a part which is not purely an issue of typing.
Admittedly, in most cases this extra complexity is worth the cost (especially with the type of high performance code written by Bloch/Carmack) but at the end of the day the job of a modern computer is to make things easy for humans and not make things easy for the computer, so in the long run it's foolish to say humans need to "think like a computer" and use a static type system, instead of allowing humans to use a more natural, dynamic programming model that is more natural for us to use.
This is anecdotal, but I find that in general a static, strongly typed language actually helps me when I am writing the program. One quarter of the time, I find that the code I just wrote doesn't make sense and end up having a conversation with the compiler and REPL until it works.
One important place where I find types help me is error handling. I typically prefer to have Maybe/Option, Either, or similar types for normal errors, and to have exceptions reserved for when the program enters an unrecoverable state and needs to crash.
There are also cases where a dynamically typed language will error during runtime, and where a statically typed language would have instead errored during compile time. It is possible to encode invariants into types, for example to force all red-black trees to be balanced.
I haven't found a case yet where such an error wasn't due to flawed reasoning on my part, and depending on the language implementation it is possible to optionally defer type errors to runtime. The language I tend to use the most also has an escape hatch to allow dynamic types if you want them (implemented as a library).
Regarding incidental complexity, in a Hilney-Milner language, most code can be written without any type annotations whatsoever, although in my language of choice (Haskell), it is standard practice to include type annotations anyway to help readability.
Encoding invariants into the code does increase the complexity, and you'll see most library writers strike a balance between complexity and correctness. If you go for an even stronger type system than Haskell's (such as Coq's, Agda's or Idris's) then it is possible to encode all invariants using the types, although type inference doesn't work as well anymore.
Static, strong typing is there to help the programmer, and typing a dynamically-typed language is probably easier. Haskell's type system helps automatic unit testing libraries such as quickcheck and hunit work better. Computer hardware doesn't care about types, but rather where the bits and bytes are and what points to them. Static typing is there purely for the programmer's benefit, rather than the computer's.
I can't say that writing software in a language that has a weak type system is anywhere as enjoyable, and I find myself having to debug my code.
