Tags are kind of pointers and when you check out a tag, you don't check out a real branch. If you also want to work on and update files, create a new branch at the same time when checking out the tag.
Not true with git. You can literally check out and start modifying and committing on top of any commit in the history, regardless of whether it is a branch, tag or a simple commit. The only problem with that is that if it is not a branch/tag you will have difficult time to find those commits later since no symbolic name (branch) points to them. That's what git calls "detached head" state. If you check out a branch, you don't end up in with a "detached head" but at the head revision of that branch. That's all.
The difference between branch and tag is only that the tag is immutable - it is a label attached to a fixed revision and cannot be moved once it is created, only deleted. A branch label always "moves" to the latest commit on that branch. However, they are both only special names for revisions.
Tags are usually nice for things like marking important revisions with a human understandable name - e.g. releases of the code. One can use branches for that too, though.
That's well detailed.
The bottom line though if you TLDR is to just use tags for marking versions of your work. And especially since we're talking about hardware design here, not software. Tag your versions. Don't try to be clever.
What you consider a "version" is of course 100% dependent on your own way of working and releasing, but if you're doing any kind of professional work, what a version is for a board is not going to be very ambiguous. Anything that has been sent to production deserves its own, clear, definite version, and any future change that ends up in production does as well. Tag them. What remains in R&D during development, it's up to you.
With that said, as I mentioned earlier, KiCad has an "archive project" function, so archiving the project in a given state takes about 2 s. Just add a version to the archive filename, click OK, and move on. If you don't want to deal with a version control tool. You don't even need to copy any file manually. It's actually faster than using git. (git could provide other benefits of course, but just mentioning the point.)
For every version that I get manufactured, I need to have a usable and, potentially editable, copy available.
So... You put each revision in its own directory? Maybe put the rev numbers at the end of the directory names?
Yes. I do.
Yeah, I do that. But I use revision control too 
Just that I like having the previous version(s) easily available for checking stuff (or maybe trying stuff out). Subversion lends itself to that, git not so much.
(Although, to be clear, I don't have every copy available, just significant ones, perhaps the versions I've given to a client or prior to a breaking change, etc. The ones not present are still in svn, of course.)
I only keep versions that have a real world PCB.
A couple of friends and I have been dealing with similar version control issues, both at work and on personal projects. We've come to the conclusion that replacing schematics with code is the way to go. We started a project called "atopile" that does just that. Here is the project repository:
https://github.com/atopile/atopileBefore starting atopile, we tried to automate the generation of KiCAD manufacturing files with KiBot:
https://github.com/INTI-CMNB/KiBot . KiBot is quite convenient to build output directly on GitHub or GitLab. But merging, diffing and reuse of design is still absent because the design still relies on schematics. We also tried Skidl:
https://github.com/devbisme/skidl . The nice thing with Skidl is that you can version control your electronics as code, just like software. That means you can branch the project, make pull requests, merge back into main etc... But because it's baked into python you have to deal with a tool that was not designed for the job. This manifest as being both unintuitive to design electronics (Python's keywords are meant for managing the flow of data, not describing electronics) and difficult to contribute to the skidl python project. So ultimately we ended up designing our own compiler.
We already have features like subclassing, replacement, units and tolerances, automatic resistor and capacitor selection. There's a bunch more we'd like to build too like an equation solver and layout reuse.
Hope that helps. Have a look and let me know what you think!
I'm a fan of incremental commit numbers with SVN. Makes it easy to reference stuff.
Also checking out per file or per folder is nice compared to git.
For a hardware project where you really aren't going to be using a lot of the software design features of git, I don't have a problem being old school and just using svn.
The version control system in Altium was SVN forever right? Now it looks like they also push git.
Any recommendation for a Kicad specific .gitignore file?