I'm fighting the fight right now of moving from SVN to Git/Bitbucket Server. So I'll give it a shot in explaining why Git is harder on newcomers than Svn, Cvs. I also work for a hardware company that isn't very good on software discipline. But we have a much larger project than what was explained above.
To start with, its Git's complexity. One of our customers (who pulls more weight with management than the engineers do), recommends that we don't move away from SVN to Git because 'Git is too complex for embedded engineers'. There is definitely something to this. The client/server architecture of SVN is easier to understand to people dealing with the basics of networking. It works very much like a filing cabinet that hardware centric engineers can wrap their heads around. You basically have a copy of what's on the server.
With beginners they look at the power that any VCS can provide and then go crazy with it. They store things that shouldn't be in there, because its convenient. Binary artifacts for instance (.a files, installers, pdfs, etc). With a new team just discovering the joys of VCS your repository is going to explode with these things, because they won't understand how it affects things. With a distributed repository like Git this will explode the repo that needs to be cloned. And people will not understand why its slower than SVN at least on the initial clone/checkout. I'm not saying there aren't any solutions to this (I'm deploying git-lfs backed by JFrog Artifactory to handle my binaries), but you have to make sure you have everything sorted out before you go to Git.
Branches are another problem, some engineers can't get their heads around it. In SVN it looks like just another copy in the repository. Almost like another directory. With Git its completely different, branches in Git are wonderful and probably its killer feature over SVN. But it adds in complexity and newbies won't appreciate them, and really know how to deal with them.
Git also gives you enough rope to hang yourself, and then gives you plenty more. You can treat it like a normal VCS system, but that removes a lot of its power.
Newbies also haven't had the pain of a malfunctioning VCS, or the pain of when it starts to go wrong. With the centralized repository the pain can be concealed better with SVN. Git rips off all the band-aids.
Git can be merciless when it comes the power it provides. A lot of the complexity can be trained away. The Pro Git book is a good place to start, but how are you going to make your developers read it and understand it? For my own migration I'll be training the entire team on how to use Git when working in our project along with JIRA, Bitbucket server and Bamboo. I think the training will last for 2 days or so. Do you have enough time to put together the training for your own team, and then conduct the training? If you don't need Git's features, SVN's simplicity is definitely easier to train for.
I hate to say it, but engineers and developers are stupider than they think when it comes to things outside their direct experience. Giving them SVN is like giving them a bike with training wheels. Its good for them to learn, and maybe you can take off the training wheels (using the CLI instead of GUI), but you wouldn't trust them out in the street. Giving them Git is like giving your 3 year old the keys to your SUV even with limiting them to a GUI. You want them to learn a bit before they get that power.
I'm moving my team from SVN to Git to get a better workflow together. With 2/3 of the team in India I have a very hard time keeping the builds clean. Running with SVN right now the developers have been instructed to commit all their changes at the end of the day. I want to find the guy who said this and shoot him, because we have people breaking the build, then running off home for the weekend, leaving the people 12 timezones away stuck. With Git, Bitbucket, and JIRA workflows set up (and permissions on who can actually commit to the MASTER branch and how it is done), I hope to isolate people's work and not having it break the build. I also hope that I'll be able to keep MASTER clean and always releasable. I can't do that easily with SVN, especially since IS has forbidden us from locking any files in SVN (because it slows the server down). My team has now had enough pain from build breaks that they're willing to learn Git and the power it has and how it will make their lives better. (For one thing I won't be yelling at them). A new team won't have this built up pain, and won't have the fear of the release manager yelling at them.