I 100% understand where you're coming from, but I view this as an advantage of static type systems. The "pain" is you having to go through your code and make sure that you change your usages of given types to match the new definitions, right? This is forcing you to make sure your code is still correct with respect to the types.
Most dynamically-typed languages let you skip this part, but this causes you to lose clarity. Is your old code still correct? Or is it just mostly correct? Are there new unexpected edge cases being introduced that you didn't bother to go check on due to faulty now-outdated assumptions?
Changing your types is a pain, I agree. But programs are just about data transformations, and types are representations of the shape of those data. Changing your types without changing every part of your program that touches those types inherently means that your program is now running on invalid assumptions. Sometimes it works fine, but I think it is better to know it's fine than to just say "Well, it seems to work in most cases."
Refactoring when you change your understanding of the domain can be a lot of work also when you have dynamic typing and lots of tests, but if the tests are well designed, I rarely feel that as painful as it was when I felt I was battling with the type system.
PS: my main experience with static typing was with c++, it's possible that more modern type systems could have improved the situation.