In the, commonly referred to as, Git-flow model hotfixes go in their specific hotfix-* branch and small integration fixes right before release go in the release-* branch. General bugfixes from the previous version does not seem to have a place.
Where should they appear? Should they be in their own bug-* branch branching off of develop (just like feature branches)?
The short answer: Yes, branches for bug fixes that are going into a planned upcoming release should be in feature branches. How you name feature branches or these branches for bug fixes is up to you and your team's standards, but they should be treated identically if you are following Gitflow.
Bart van Ingen Schenau's comment brings up a good point.
Gitflow has five branch types: master, develop, hotfix branches (prefixed with hotfix-), release branches (prefixed with release-, and feature branches. The master and develop branches are long-running branches and you do not commit directly into them. The release- branches are made to draw a line for a particular release and then support bug fixes between the identification of the next version and the release. The hotfix- branches are specifically for critical, out-of-cycle releases into production. The feature- branches are for development of individual features for some future release.
Coming from environments where PRs are used and aside from an individual developer committing to a feature branch, nothing should be committed directly into master, develop, or a release branch. This ensures that every change is code reviewed, along with ensuring appropriate test coverage and passing tests in a CI environment before changes go in. I would be opposed to any commits directly into one of these branches, although it appears that Gitflow by itself doesn't have any problems with committing pre-release bug fixes or changes directly into the release branch and then pulling them into development and then feature branches.
In your particular case, a release- branch isn't an appropriate place. The software has already been released and is in master. Once a release is merged into master and tagged there, the release branch for that particular release has outlived its purpose and doesn't necessarily need to exist anymore. If you're active in cleaning up your branches (which I think that everyone should be), then this isn't even an option.
If your fix isn't critical, then a hotfix branch doesn't seem to fit either. The purpose of a hotfix branch is to let someone get critical changes into production very quickly without interfering with ongoing development. Using these should be the exception rather than the norm for a development team. In general, critical hotfixes should be an exceptional case.
The only thing left is a feature branch. Note that the section of the page linked to in the question about feature branches even says that feature branches are "sometimes called topic branches". If your change is targeting any upcoming release and doesn't meet the criteria for a hotfix, it should be in one of these branches.
If its a single commit then just make a well identified commit and push it on top of the development branch, else create a feature branch.
There is also a comment from the git-flow author saying exactly what you are asking: Missing bugfix branches #24
There's a useful answer here by @Dominik - https://stackoverflow.com/questions/31126132/gitflow-feature-vs-bugfix-branch-naming/31126413#31126413
Bitbucket has default branch prefixes that include Bugfix. The idea is that a Bugfix can be any bug fix in a develop or release branch, but a Hotfix is specific for a fix to be directly applied to master (i.e. a production bug fix):
