Git is somewhat confusing to use, but not enough so that anyone really cares all that much (besides a few people who really care) and that is not a recipe for easy replacement.
There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason.
Also (sorta) darcs, and hopefully pijul. I sincerely hope some patch-based version control can catch on.
pijul regrettably seems to be broken most of the time, but I don't think it's irredeemable.
The general consensus is that putting big files in git means you're doing something wrong and the problem is with your environment not git. (or there are special-purpose tools for your kind of workflow which handle the specifics of your use case, like CAD/CAM/etc.)
Workflows like that generally don't fit into nice little boxes anyway the way source code management does.
This is not a “general” consensus. It’s a consensus among hardcore proponents of git. I love git, it has made my life better. I still think it’s large file support story is shitty/suboptimal, and there are valid use cases where a general purpose VCS is used to track large binary assets along code and git would do well to be a general purpose VCS. It’s a limitation of git. It’s not a fatal limitation, and git still has enough benefits (which include availability and mindshare), but it is still an unfortunate limitation and somewhat ironic for a tool born in a world where everything is just a “sequence of bytes”.
I would say the other kind of for loop, a “for x in y { body }” loop, is very intuitive and obvious to most English speakers. We use idioms like “for each A, do B” all the time.