Part of the problem is we were all newbies at some point.
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 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).