When to drop support for deprecations in git-flow / semantic versioning

tl;dr: One way to achieve this is to simply remove the feature on develop after the last 2.X release branch is made. Or feature flag the removal, and disable it on the first 3.X release branch. If you can't do either of those for some reason, it's still OK to do it on release.

Details:

Usually you can treat dropping this feature the same way you would treat adding a new big feature by simply merging it into develop. The only difference is that you need to make sure you get the timing right such that you don't complete the code removing the feature into develop until the last 2.X release branch is created. The next release branch that comes off of develop will have the code and will be the 3.X release. If the issue is that you don't know for certain when the last 2.X release will be, you could either wait until you do know and then merge the removal code into develop, or, consider feature flagging the removal with a config change. Then your change on the release branch whenever you create the 3.X version would simply be toggling the config.

That being said, perhaps ultimately it doesn't matter anyway:

But according to git-flow, a release-branch should only accept bug fixes.

Note there is no such thing as a Git Flow Authority which dictates what you must do. There is a popular standard Git Flow, but here I use the word "standard" to just mean "original" version that many companies use as a guideline. It is not "the" standard, as no such standard exists. I think the particular text you're referring to regarding release branches (emphasis mine):

This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the develop branch). Adding large new features here is strictly prohibited. They must be merged into develop, and therefore, wait for the next big release.

Note even "strictly prohibited" is a (strongly) suggested best practice. There are no Git Flow Gods that will strike you down if you ever violate this rule. Besides, in your case, it could be easily argued that removing a deprecated feature on the release branch is not considered "adding a large new feature". (Even if we ignore the distinction between add/remove and new/old, perhaps the feature being removed is not "large".) Regardless, sometimes new large features do get added to a release branch, for a variety of reasons. This may violate best practices, but in the real world it's not always possible to follow best practice 100% of the time. Think of Git Flow as a guideline to work in, when it makes sense to do so. Note that Vincent Driessen specifically points out in the Note of Reflection that he didn't intend for Git Flow to become "dogma or panacea".