git checkout isn't designed to revert files. It's designed to allow you to check out a particular version of a file without changing the branch you're on.
"Reverting a file" is a higher level concept you can build on top of that, but that's not the fault of git checkout. Also arguably to truly revert a file you'd have to follow it up with a git commit.
I would also point out that recent versions of git have added a git switch subcommand because of some of these complaints.
Well TIL after using git for 8 years. And yet 90% of the time what I'm typing is "git checkout --" which has nothing to do with the branch of the file, im just getting rid of something. It's a bad UI when the obscure case is favored over the common one, and believe me I can pick out 100 other cases.
This is interesting. I find myself using checkout to check out individual files extremely rarely. It feels like a bit of an anti-pattern to me. What I do instead is commit the changes I intend to keep, using some interactive form of commit (usually git gui) followed by git reset --hard to remove whatever I don't want to keep.
The underlying rule is never to make destructive changes on a working directory that also has changes I intend to keep. This massively reduces the risk of data loss by accidental fat fingering of a command.
"Reverting a file" is a higher level concept you can build on top of that, but that's not the fault of git checkout. Also arguably to truly revert a file you'd have to follow it up with a git commit.
I would also point out that recent versions of git have added a git switch subcommand because of some of these complaints.