They aren't really. It's basically like getting an auto generated ref/branch name for each new commit, with convenience rewriting every ref when you rebase.

It's a bit more convenient if you prefer referring to a non-leaf commit directly rather than relative to the leaf branch a la master~2

change ids are more analogous to commit messages than branches, eg suppose that in a feature branch you have a "Delete deprecated classes" commit; in git there is a clear idea of "cloning" this commit (eg rebase, cherrypicks, maybe reverts) and the common sense that the new commit inherits the same commit message. Change ids are the same thing but in hex id form that can be created for every new commit/stash/index.

They allow for example to identify all the clones of a commit and they allow to give stable identities across rebases eg suppose you rebase a typo at the beginning of a feature branch without change ids a reviewer sees n new unrelated commits while with change ids it is possible to clearly identify which commits where changed/added/removed since the previous review iteration.

You amend or rebase a commit and can still reference it by the same name.

A branch is mutable and holds only one version of history at a time.

If you never rewrite history, you could achieve something similar, but it precludes you from having a “tidy” branch.

Whether or not you’re into rewriting history is a different discussion that has been hashed out over and over again.