It does make sense. If you think about it--named branches are essentially tags which replicate themselves in every child commit. So you can end up with two different heads (tips) under the same named branch:
@ changeset: 3:fe8f1a13eb95
| branch: b1
| tag: tip
| parent: 1:33674427026e
| user: ...
| date: ...
| summary: Third commit on branch b1
|
| o changeset: 2:0ad872ebd9b9
|/ branch: b1
| user: ...
| date: ...
| summary: Second commit on branch b1
|
o changeset: 1:33674427026e
| branch: b1
| user: ...
| date: ...
| summary: First commit on branch b1
|
o changeset: 0:18c33e4b94ed
user: ...
date: ...
summary: First commit
Which seems a little counter-intuitive. On the other hand, bookmarks are like tags which move from parent commit to child commit. They are guaranteed to be on only one head. If you try to reproduce the above commit graph with a bookmark named b1, the changeset # 3 will not get the bookmark name--it will be anonymous:
@ changeset: 3:c4dd0b7f9844
| tag: tip
| parent: 1:0c00681b3cfa
| user: ...
| date: ...
| summary: Third commit (on bookmark b1 or...?)
|
| o changeset: 2:f4e700efd4a6
|/ bookmark: b1
| user: ...
| date: ...
| summary: Second commit on bookmark b1
|
o changeset: 1:0c00681b3cfa
| user: ...
| date: ...
| summary: First commit on bookmark b1
|
o changeset: 0:f2cc94a68cf0
user: ...
date: ...
summary: First commit
Which meshes a bit more, in my opinion, with what a branch should be--a single line of development.
Now, to answer your question about use cases: given the above, you would want to use bookmarks in a repo where you're already using named branches when ... you have multiple heads in the named branch and want to name those.