Branches are temporary and arbitrary constructs. Your branch will eventually be gone - the branch name is then gone as well... or, well, it might live on in the default commit message of a merge commit.
Furthermore, in most flows the branch is an ownership thing: Your workflow will probably have personal branches, team branches, project branches. One and the same commit will eventually exist in many of those. More to the point:
- It will probably be created on a personal branch - most importantly named after the developer.
- It will next be merged into a team branch for integration - most importantly named after the team.
- It will eventually be merged into a project branch for release - most importantly named after the release step ("development", "rc", "release", "master", etc.).
All those kinds of branches have little reason to be named after an issue.
For 1. it is convenient to also include the issue, because you will likely work on more than one issue at a time, e.g. one in development, one in review. Given that issues usually have an assignee, one may then drop the owner from the branch name - this becomes inconvenient, though, in flows where after-development-but-before-closing you reassign the issue to other people (reviewer / tester / product owner / etc.).
For all other branch types it will be detrimental: What of, say, a branch containing 20 issues... pretty long name, huh?
Long story short:
- It is important to reference the issue in the commit message.
- It is not (generally*) important to reference the issue in the branch name.
*- "generally" might be beaten by the requirements of specific third-party tool chains, most likely for auto-generating
<tracker>-to-<anything else> links. Those links, of course, behave just like branches and commits themselves: Those to the branches will vanish (with them), those to commits will remain (with them).