I'd recommend another guide. "Pro Git" by Scott Chacon is excellent and welcomes patches, source for the book and its translations are on GitHub http://www.git-scm.com/book
http://git-scm.com/book
And so, without an explicit recommendation, it's easy to miss out on its well-organized narrative, or its superb ninth chapter, Git Internals, which explains the "why?" of Git and is probably one's best shot at grokking Git. (See parent's sibling comments for evidence.)
Version control only makes up a part of the whole development process, and plenty of coders out there manage without any at all.
It can seem a complicated nightmare until you grok how it really works. And if you have preconceptions getting in your way, yes, a book can be a very useful tool to give you that "Aha!" moment.
Once you stop someone thinking "It's a log of patches" and make them understand "It's like VM snapshots logged in a linked list" all the weird difficult stuff just Makes Sense.
(That is one reason I stay away from security work. The theory is fascinating, but the practice is just not fun.)
OpenBSD's kernel development is presumably run differently (IIRC there is a much smaller number of people trying to directly feed into it for a start, which was a key problem with Linux at least at the time Git was birthed) so processes and tools that fit their needs will look different. Either they haven't had enough trouble with the older tools/processes that the effort of an infrastructure change is worth sinking time into, or they have other concerns with the alternatives (security, as someone has mentioned above, and code maturity concerns may be involved, though the latter much less now as it has been pretty solid for some time), or maybe they intend to move but just haven't decided on an alternative yet.
They moved to a DVCS to solve some of the workflow issues, then Linus created git in large part because of the licensing issues.
Another detail missed in my previous post: If I remember rightly there were a couple of F/OSS DVCS's in development at the time, but he chose to write his own as some of them were not yet near stable and the others didn't quite work the way he wanted. I dimly recall some criticism for choosing a commercial product prior to git, and that decision was for much the same reasons git was created instead of using one of the other available options.
This is not a scheme that should be emulated. Compartmentalization/modularization is not only useful at the micro-level in code, all of it's benefits are available when applied at a project/organization level.
For another point of view, consider this page: https://wiki.freebsd.org/GitDrawbacks I think nearly everything on that page is misleaded/misleading, or flat out incorrect, and they failed to identify the technical limitations with git that would apply to them. Other viewpoints are nevertheless useful.
(Actually the BSDs use a handful of massive monolith repos, but that is just nitpicking/)
(Disclosure, I work at a company that uses git at a _much_ larger scale than the BSDs use CVS. Many many times larger than all the OpenBSD repos combined (http://www.openbsd.org/cvsync.html). The trick? We don't have a handful of repos for the company, we have a handful of repos for each team. Each project gets it's own repo. Our build systems, deployment systems, and dev environments are tooled for this. One of the things it even allows is different teams using different VCS, if you're on a team with a bunch of luddites you can still use SVN for your code, and you will be able to build against other code and other code will still be able to build against yours.)
The source code for a system is one of the more valuable assets produced by a software development team, and managing source code is heavily about managing risk. Losing source code means losing work (money and time). Deploying source code too early means exposing the users of your system to code that might not be adequately tested. In distributed development, accepting unsigned patches means that your system might include untrustworthy code... the list goes on and on.
Part of the reason that git is complex (and this can be said about any serious source code management system) is that it solves complex problems. Fifteen years ago, Jamie Zawinski said this about Mozilla... I think it's also true for git:
"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. "