A better way of explaining will be to specify the use cases how branching and tags are used. Though your analogy is mostly correct, a novice programmer will have little clue how to use branching and tagging in real life, and why should he use tags (when branches can also be named and will do just fine in remembering commit locations).
Branches are useful when you are developing several features, or have a team who are developing several features/solving bugs. In that case, say a team of 5, each person can be assigned to each issue, and he/she can create his/her own branch to work and solve that issue (most git hosting services can do this automatically). Now say, you have finished coding the feature, tested it and it works fine, you can simply send a merge request to get it merged with the master branch.
This ensures several things
master, and he/she can do a code review of the code before its pushed to the main master branch. Now say, you have several features coded this way and merged into the master. Your product is now ready for a new release. This is where tagging comes into play. After a few changes are merged into master, you can add a tag to the latest merged commit, and point it is a new release - version-1.2 for example. The added benefit of tagging - you can also add change logs and release notes in each of the tags that you created - thus maintaining a consistent software cycle over time.
Many git providers have CI features that can automatically build tagged releases to a container, and auto deploy it. So tagging can greatly help in your release cycle - merge features into master from branches, create tags when you have a bunch of features, get it automatically deployed to a staging server, test it there, and release it to production if everything looks fine.
So in short