Apologies for the incorrect credit.
I've never done it, but ReleaseTodo seems to indicate that running addVersion is done as one of the early steps in the process.
For major and minor releases, I think this makes sense, because you'll be making a new branch early in the process. At that point the parent branch should get a version bump, and the subsequent release work will be done in the new branch, presumably with the correct version number already present.
For bugfix releases, I think it makes more sense to run addVersion just after tagging the release – one of the last steps. That would have prevented the problem I ran into. I ran "ant package" on branch_5_5 some time after 5.5.0 was fully released, but I got 5.5.0-SNAPSHOT filenames instead of 5.5.1-SNAPSHOT.
Regarding the brand-new bug-fix Version entry being deprecated: This makes no sense to me, especially since it causes an immediate test failure in the test that the addVersion script runs after making changes. I can see with "git diff" that the script did correctly add deprecation annotations to LUCENE_5_5_0.
If the addVersion script were being used to add 5.5.1 to one of the 6x branches or the master branch, then it WOULD make sense for the new entry to be deprecated. Perhaps I was not using the script correctly for my use case, or the script needs some detection code or the option you mentioned to skip deprecation.