Using SCM for teaching development to newbies is already adding unnecessary complexity (even in a collaborative setting, flows are complex enough to distract from more fundamental topics).
If you're a software developer getting to the point where using git is needed you should absolutely know the core concepts behind public key cryptography, it's going to come up everywhere and you can fuck up big time by publishing the wrong part.
https://github.com/digitalocean/tos
There are plenty of text file versioning use cases I think, from configuration files for system administrators to LaTeX papers for science students who could benefit and should have an easy path to using it.
Heck even if you want to host a static site you probably want to just be on github these days.
Yet to me there is no reason for version control to be this complex. The current github + git universe is locked in, but I don't see why it should be optimal.
There is no such thing as a project not complex enough to warrant a SCM/VCS. There's probably an argument that there is a case where a DVCS is unnecessary, but if you aren't actually doing distributed work there's no reason you need to be aware of more complexity in a DVCS than a non-D VCS.
I have a program I wrote that helps me straighten scanned images in bulk. It took maybe an hour to write because I did it in D and was not familiar with the language. Though I have used it for years now and made a few tweaks I have never felt the need to have it in any kind of source control.
I and most developers I know use git or similar for projects of any size, often even if it's "just" a single file or a "one-off" change (because it rarely stays that way).
I would have agreed in the days when Subversion was the closest you could get to "easy version control" but these days in my eyes "the point where using git is needed" is not far from the point where you start making changes to an existing file.
The alternative is just doing what you always do on every project: run "git init" and occasionally do a "git add -i && git commit". Even if you end up with a lot of non-descriptive snapshots name "WIP" at least you have something resembling a chronology and you can track changes across multiple files at the same time.
If your hobby projects mostly consist of single files with thousands of lines that are easy to unambiguously make copies of for backups, I won't judge you, but your experience is definitely not universal.
Or I just let my backup software handle it. Automated daily backup supplemented with manually initiated backup if I need a specific point-in-time snapshot.
This isn't rocket science.
I remember the first time I tried to use SCM. It was a collaborative project in college, and our professor recommended we set up a CVS repo (at that point in time, he probably should have recommended SVN, but we didn't know that). We spent about an hour trying to set one up, and eventually concluded it was a waste of time and that we'd just e-mail each other .tar.gz files of the repo and manually sync them. Eventually we did break something and have to go back to the last .tar.gz to un-break it, which wasted another hour or so, but with the friction we'd seen trying to set up CVS, that still seemed preferable to trying SCM again (although it also showed that SCM would have been helpful had we been able to set it up).
GitHub with a password is much easier than setting up a CVS repo as a newbie, and had that been an option then we likely would have succeeded. But I'm much more doubtful that we would have tried and succeeded at token authentication; I also remember how mystifying I found it the first few times I worked somewhere that required it, even understanding the underlying concepts of public key cryptography. The problem is understanding the tools well enough to get it working, and working across operating systems (Linux doesn't have PuTTY; Windows doesn't have the Linux command-line tools; etc.).
When I eventually started using SCM reliably, it was with Mercurial + BitBucket + a password. I recall that I kind of knew I should set up a token, but my first few attempts were unsuccessful (largely due to most instructions being Linux-focused, and being on Windows), and thus I kept using a password for years because making progress on development seemed more useful than figuring out a token. I did use randomly-generated, lengthy, unique passwords, so the risk of using a password seemed pretty low.
So I think this is a bad thing for newcomer-friendliness. Perhaps it is an opportunity for GitLab and whatever other competitors still exist. But I would have rather seen it remain an option, perhaps based on new users choosing whether they're new to Git (allow passwords) or experienced (require tokens, but be able to change it in case they're only experienced with Git, and not with tokens).
I mean, ideally, that'd be great. I don't think there's any fundamental reason things can't be this way, many of these complexities are completely incidental, rather than inherent.
> Is it really too much to ask a newcomer to invest some hours into learning something these days?
No, but when I'm learning something, I prefer for my time to be spent on important stuff, not wasted unnecessarily.