I've been thinking about this for a while. I don't use Clojure but I do follow Rich Hickey and have watched a few of his talks, where he makes similar points. Folks often talk about types as abstractions but they're actually concretions, they are concrete choices about what information you want to keep out of all possible choices. And like concrete in real life, it's costly to change the shape of something once it's set. This may or may not be an issue depending on where you program is running, in closed systems like a compiler it can be a great benefit, for open world systems which must use non-elegant models, must deal with state and time, must have effects and be affected, and must change in ways you can't predict, the cost is much higher.
I talk about types because most of the "make invalid states unrepresentable" dogma comes from proponents of languages with extensive static type systems, and the idea is to use the type system to define all forms of legal states.
> it's costly to change the shape of something once it's set
But in a dynamically typed language you also have that problem. Except there the shape is a hidden assumption and the type checker won't tell you all the places you have to change.
I think you generally make less assumptions about the shape of data in dynamic languages.
I find writing code in dynamic/statically typed languages very different from each other, and when I hear proponents of either complain about the other (types slow me down! / too many runtime errors!) I sort of assume they're writing code like they would in their preferred paradigm and running into walls.