True, you need to know what is and isn't possible in the borrow checking model to avoid learning it the hard way after writing the code.

There are some gotchas that you need to learn (e.g. self-referential structs won't work, or & returned from a &mut method won't be shareable).

But besides a few exceptions, it's mostly shared XOR mutable data in the shape of a tree. It's possible to build intuition around it.

This sounds like a reasonable complaint, that refactorings are too complex in large programs.

But I have a hard time to envision any other solution than "better tooling for refactoring".