Deleting the branch is, in general, the right answer. But there are a lot of fiddly little knobs to turn here. Some of them, you can just wait (about a month) and avoid dealing with. If you don't want to wait for the various copies of the repository to shrink on their own, though:
In this case, we have already deleted the branch and recommitted the work on a fresh branch, but the size hasn't changed yet ...
First, remember that Git is distributed by nature. Each repository is (at least in principle) wholly self-contained and independent of every other repository. So when you say that the repository has not yet slimmed-down, the obvious first question is: which one?
Any change you make to any one repository won't affect any other repository, at least, not until you cross-connect the two of them and tell one to fetch new work from the other, or push new work to the other. If you are doing all of this in a test clone, that's fine, just remember that the test clone's results will be specific to that one clone.
The immediate next problem is that Git, by its nature, ‘wants’ to make more copies of everything. Commits are like some viruses or diseases: connect one Git to another Git, and the Git that didn't have the commits has them now. The Git that did have the commits, still has them. When you do finally remove the commits from (say) sixteen clones, it will be absurdly easy for anyone, anywhere, who does have the commits in their clones to accidentally reintroduce them to the fixed-up clones, from which they'll spread back to all the others. That doesn't mean you can't be rid of the commits—and the "only reachable from one branch" nature of the way you have them now is going to simplify things quite a lot, as you merely need to make sure that no one else restores or merges that branch from their clone.
For lots of useful background, I recommend reading and working through the web site Think Like (a) Git. Once you have digested what's there, the way to shrink your repository is:
Make sure the commit(s) that have the large file(s) are unreachable. In your specific case, deleting the branch name gets you most of the way there: they were reachable from that branch name, and through that branch's reflogs. Deleting the branch removes its reflogs as well, so that path is now cleared out.
The place from which those commits can (probably) still be reached is in your HEAD reflog. Running git reflog will show you all the HEAD reflog entries (the default action is show and the default reflog to show is that for HEAD). You could selectively expunge each such reflog entry, with, e.g., git reflog delete, but it's easier to just delete all your HEAD reflog entries with:
git reflog expire --expire=now --expire-unreachable=now
Note that this removes all your ability to restore otherwise accidentally lost HEAD commits, so be very sure you are OK with this before you do it. You can leave out --expire=now since the deleted-branch-specific commits should not be reachable from your current branch—I'm showing the "nuke it from orbit" variant of the command here.
Then, run git gc --prune=now. This is the last step of the "checklist for shrinking a repository" from the git filter-branch documentation.
This will take care of all of the various items needed to rebuild pack files and/or discard loose objects that hold the large files that are no longer reachable from any external name. That is, no external name points directly or indirectly to any commit that, through its tree or one of its tree's subtrees, points to the blob object holding the file. Thus, the gc command will orchestrate the other commands (git repack and git prune) that will delete the unwanted objects.
(Note: If you are using .keep files to retain old packs, you will have to remove those .keep files and allow those packs to be destroyed. If you're doing this, though, you probably are not asking this question in the first place.)
