Tags are cheap. They don’t consume a lot of resources. Your version control tool won’t slow down if you use lots of them. Having more tags does not increase your responsibilities. So you can use them as often as you like. The following situations are examples of when you might want to use a tag:
When you make a release, apply a tag to the version from which that release was built. A release is the most obvious time to apply a tag. When you release a version of your application to customers, it can be very important to later know exactly which version of the code was released.
Sometimes it is necessary to make a change which is widespread or fundamental. Before destabilizing your code, you may want to apply a tag so you can easily find the version just before things started getting messed up.
Some automated build systems apply a tag every time a build is done. The usual approach is to first apply the tag and then do a “get by tag” operation to retrieve the code to be used for the build. Using one of these tools can result in an awful lot of tags, but I still like the idea. It eliminates the guesswork of trying to figure out exactly which code was in the build.