I've installed multiple different source control tools before (and apparently still have TortoiseSVN and TortoiseCVS installed), but they puked over my projects' neatly organized folders with special files and junk

I use TortoiseGit and GitHub for my upstream repo. Its easy enough to setup and there are guides on youtube etc on how to do it. I would suggest you always keep another manual backup as well because of the nature of the git workflow systems. I usually write some powershell scripts or bash scripts to do file copies to my storage device daily. Probably seems overkill, but having a practical backup solution is a good idea.

And the larger the project, the more rage-inducing it is to lack modern (distributed) version control functionality.

"...more rage-inducing..." LOL.... As if everything else - modern functionality - is Iess rage-inducing, but rage-inducing never the less. LOL

Git explicitly tries to prevent editing by only referencing everything (files, folders, revisions) by their SHA-1 value. Presumably this is "secure" as long as you don't have a preimage attack on SHA-1 that runs in minutes/seconds. It is necessary in the case of a distributed system, too, because otherwise you have hardly any way of telling what's authentic and what was changed and tampered with.

QFE.

AFAIK this is actually one of the substantial philosophical differences between git and mercurial (hg) -- git is architected with security truly in mind, rather than something which is sort of an assumed by-product of revision control. Linus wanted to be sure that if the linux kernel source code was contaminated or just plain borked, accidentally or intentionally, that the warning flares would go up instantly. If you're in an environment where you cannot trust contributions (or where the consequences of being wrong are serious) then this additional attention to security might be important to you. I forget which of the *BSD's kernel repository was recently attacked, but it was, and a lot of work was lost, deadlines were missed, and much woe was had. There's always a possibility that disagreements between devs can escalate into malicious actions.

This also speaks to the distributed model in general somewhat -- with a centralized system you have to maintain the security of the repository and make sure its backed up because that's the one place that maintains the entire history. When you pull down a local copy of this source tree you only get the info that's relevant to that time. In a distributed system, *everyone* has the entire history, and even if the "central/official" repo was destroyed, it's solved by simply pushing it out from one of the devs' local copies. Linus has said that he doesn't even bother to back up the linux kernel source anymore, because he can just assume that its been replicated hundreds or thousands of times by devs all over the world -- way better than any RAID or backup strategy. Of course, you have to have many active developers before this is true, its just nice that the robustness of the system is directly related to how much its relied upon.

There are some things not mentioned above, which had a big influence on my workflow.

1. The git two step use of the list of staged files (in the index). I don't know what other version managers that use this. Anyway, at first I found it awkward to use, just adding work and effort. But then I learned to use it efficiently. When developing a new functionality, I continuously move changes back and forth between staged and not staged. Especially, I move hunks and lines, not complete files. Typically is that you have some changes that should go into the commit, and some temporary changes that are used for testing. So the temporary changes are not staged. There are also several changes that I "randomly" add to the source code during the investigation of how to best design the change I want. This way, it is easy to revert the temporary changes, while still keeping the staged changes. I use "git gui" for this, as not all git UI tools support it.
2. There is a conflict in version management. On the one hand, you should check in as frequently as possible. But on the other hand, you should not check in things that break functionality for others in the development team. If you check in frequently, it is usually easier to merge from the origin. This is helped by distributed version management. You can check in as frequently as you want, but should wait with the push until you are confident you don't break things you are not supposed to break. It is a tendency of programmers to hesitate to check in until they feel confident with their change, which can lead to several weeks until there is a check-in.
3. Git is very advanced. What is a little tricky, is that it is possible to rebuild the tree. This can easily lead to problems if you don't know what you are doing. It should not be a problem in a single user environment.
4. Github uses git. Sure, there are other alternatives, but Github is one of the better?
5. If you have big projects, you need to organize the version management into sub projects. You want to define a "product" that consists of defined versions of libraries. That is more or less supported by the version control systems. Maybe the strongest one here is ClearCase? But I wouldn't recommend ClearCase.