If you’re working on a large, unstructured project that you’re trying to refactor, you’re problem probably isn’t with the types. It’s that the people working on it used types as a crutch so that they thought it was okay to write classes that were thousands of lines long with giant methods that are impossible to make sense of.
The interview question I’ve been asking lately is about object design. I tell them not to put things into one big method—that it needs to be readable for junior devs. They always ignore me. The ones who struggle the most are the ones who try to do it in a staticly types language (which I’m sure you agree is crazy to use in an interview for a tiny problem). Their mental model forces them to think about types first, and they then can’t think about anything other than that and just making the thing work.
If you aim to keep your objects and you methods small enough that anyone can read them and make sense of them, then you don’t need static types and refactoring becomes easy. There are plenty of developers of mediocre talent who never use types and are able to build huge features and projects quickly and with high maintainability and flexibility because they write code that sticks to good object oriented design principles.
A class I work on regularly has become so big that everyone, especially the more senior, more talented engineers at my company are too afraid to touch, let alone try to refactor. It’s stayically typed.