In my experience, the "refactor the world in a separate branch" strategy is always a giant mess. The initial work is perhaps simpler but the final merge is always horrible and the full impact of breaks isn't found until the merge is committed and you're stuck in "fix forward" mode because reverting is an unacceptable choice due to the cost of merging.
I'm not sure the overall cost to the team wouldn't be lower if these sorts of rewrites were done in place. (Also it's not really a refactoring if it's so big you can't do it in branch.)
Not disagreeing, but a way to avoid this is to pull changes from the main branch into the development branch every day, and write your new subsystem 'beside' the old one until it is ready to go. If you do it like this, it's not much easier for the branched developers than working on the trunk - it's still a moving codebase - but it does mean that if you cancel the rewrite there isn't any pollution to the main branch.
The scenario you called out, where the rewriting work might be abandoned/cancelled, is the only scenario I can think that makes a separate branch actually better. For cases where you're confident that the work will not be cancelled, you have the same amount of work to push the rewrite back into the main branch constantly as you do to constantly keep the child branch in sync. i.e. If you can pull from the main branch into the rewrite branch and build/test successfully, you can do the same in reverse. If you cannot pull from main into rewrite and build/test successfully, you're just postponing the pain to the end when you'll dump it on the rest of the team when you finally merge back and break everything in the main branch.
The disadvantage is that if your rewrite branch is halfway finished, you _can_ merge in the latest main branch, but if you do the reverse (which is exactly as much effort), you're blocking the other developers until your rewrite is done.
This is only true if you assume that the rewrite branch will be broken the entire time. You're only blocking the team if your work will be unusable until it's done. If that's the case, then you're also assuming at some point in the future you'll complete the work, get everything working again, and then merge everything back to master. It won't likely play out that way, though.
More likely is that:
* Your child branch will be test-broken and likely build-broken almost the entire time you develop.
* You'll stop taking frequent merges as they become painful because you're clearly not doing the work to patch everything up (and can't, because you've broken everything and likely can't even run tests).
* You'll be "almost done" and then spend three weeks trying to get everything building and testing again.
* You'll tell everyone to freeze checkins because you need to get merged and it's impossible because the branch is so far out of sync and and you're now conflicting on every tiny change.
* You'll finally push your merge back with half the tests disabled.
* The entire team will spend another month cleaning up the mess.
I've never seen a big feature/rewrite branch play out any other way.
I'm not sure the overall cost to the team wouldn't be lower if these sorts of rewrites were done in place. (Also it's not really a refactoring if it's so big you can't do it in branch.)