I've heard that argument before, but I've never seen that sort of behavior in practice. If anything, statically typed (or heavily annotated) codebases I've worked on have been much more amenable to change when it comes to adapting to "code that doesn’t neatly fit the puzzle’s constraints" as you say. The refactoring tooling and assurances provided by the type system tended to make people more willing to start rethinking their "puzzle" (type design) earlier in the process, rather than doubling down on a flawed model.
I've seen people do similarly great work in highly dynamic languages, too, so this isn't a "static > dynamic types" statement; just an anecdote in contrary to your claim.
The puzzle is not some inherent problem within the one you’re actually solving, it only arises because of limitations of any type system you choose to work with.
I don't think that's true. But even if I did, it doesn't address my point above that, in return for having to solve the "puzzle", programmers in more strongly-typed languages gain numerous other advantages.
I've seen people do similarly great work in highly dynamic languages, too, so this isn't a "static > dynamic types" statement; just an anecdote in contrary to your claim.