But checkin had always did the same thing, be it in VSS or PVCS. Sure, there'd be varying capabilities, differences in tooling, but concepts were the same. Git wants to be different for the sake of being different (even if we assume for a moment that one should know anything about DAGs in order to use version control, which is pretty laughable by itself).
I bet you have no problem in remembering what git pull, git checkout, git add, git commit and git push do, isn't it? For everyday work it's enough. You have problem in mastering git, all these nifty logs, diffs, indexes, refs, heads, remotes and other stuff. Other VCS have complex concepts too besides checkins.
It's not even remembering whatever non-standard terminology Linus came up with (although when I am feeling particularly curmudgeony I don't even want to know what push is, and why doing a commit isn't enough). It's a) having to deal with it in the first place, because the management decided to cargo-cult it, even though we are not developing anything resembling Linux kernel (there were no issues using TFS before, they just decided that they want to give Microsoft even more money and got a commercial Github account), and b) that I even have to drop to the CLI in the first place for operations that in any other VCS I could do with a couple clicks right in VS GUI. With TFS I had to use command line maybe once a year, and usually for something not strictly necessary. With SVN it was maybe every c9ouple of weeks to fix up the repository it messed up, With Git it is way too often.
Whatever technical advantages of Git are (and technically it is good), I think it fails as a tool to let me do my job easier.