> There has to be something I'm missing...
Some of your replies have already touched on a few points, so I'll add a new one: type systems can be more than a lot of work, they can be wrong. You do allude to "formulating the type is too laborious", but it's more than that.
For example, let's take the perennial question of object-relational mapping frameworks. "Object" isn't a great name for it because the real goal is usually a specific syntax (method calls) and type-safety features (make getID return an Integer, not a String). But there's a problem. "ID" is not the name of an attribute. It's a token in a SQL query. In the database, "ID" can be an Integer today, a nullable String tomorrow, and deleted next week. The type of the underlying data comes from the schema, not the application code. So there is inevitably a mismatch. Unless you understand there is some dynamism there and model the code that way.
The same thing goes for strongly typed HTTP or SOAP clients. Also anything that parses input on the fly.
There are absolutely places where the application can decide something has been validated and then apply that information to some data with a strong type, but there's a tradeoff there, too. You end up requiring that sort of validation-and-tagging in all sorts of places where it's irrelevant. Compare creating an XML DOM with using xpath, xquery, etc. You could create a giant graph of all the nodes in your XML document. Or you could just provide an expression that does pattern matching. There are places where either is handy, but the latter is almost always more flexible.
Now, there are limits. Generally, well-typed data is easier for compilers to understand and optimized. That is, strongly typed data structures are important. But, honestly, most code isn't brand new data structures.
Anyway, there's certainly balance to everything, but people need to keep in mind that type systems are a hammer like anything else. They can be misapplied harmfully, too.
Caveat: It's possible to use generic programming and higher kinded types to work around many of these limitations, but I'm writing this blurb to people who are "application developers" or otherwise are big on object-oriented programming. If people are interested in how type systems can be more flexible, we can talk about that too. My point is that they overwhelmingly aren't used that way.