This. Also, hold on to the commit before you started refactoring (preferably by placing a temporary branch there, in order to avoid premature garbage collection). Then after your refactoring is done, `git fsck` and `git diff --stat $old_branch..HEAD` to verify that you did not lose any important content during the refactoring.
That is true in general. However, in the context of bfg-repo-cleaner, that doesn't help, because the purpose of the bfg-repo-cleaner is to completely remove commits that match the criteria you give it. I say this not to "correct" you per se, because you are correct, but to ensure that people using bfg-repo-cleaner do not believe that this will help them.
The "correct" course of action prior to using the bfg-repo-cleaner is to make a complete copy of the target .git directory. I've used it many times and it seems quite reliable, but if nothing else, that's a good defense against terminating it halfway through accidentally or something. (Of course even without that, you shouldn't be operating on the only copy of your .git repo anyhow since it is almost certainly somewhere else, too, or you wouldn't be having the problem bfg-repo-cleaner is designed to solve in the first place. But losing your own local branches and work is still a pain.)