As for git's complexity, it's all in its completely opaque display of its internal state. A chain of deltas - diffs - isn't complicated. It's all git's (perverse) desire to follow the exact-same command-line interface as cat and awk, when neither contain persistent state.
Word shows pretty bubbles next to sections that have been edited. The bubbles are color-coded so it's easy to tell who did what. The edits can be accepted, rejected, or further modified with a couple of clicks. There is no list of commands or keyboard shortcuts to memorize. Just a bunch of icons, menus, and clicking around.
Word doesn't require your content to be made up of neat lines of verse, either. Natural languages don't organize themselves into 78-char lines. It should be OK to edit a few words in a long paragraph of prose. Even Wikipedia's messy "Revision History" is probably better than git in this regard.
It is a horrible representation for stuff where edits may consist of both typo fixes, and separate wording changes in a single sentence - where you might want to accept change to one word and reject change to another word, despite that they came from a single "commit" to a single line.
For collaborative text editing both word's track changes and google docs features are far superior to git.
Word's review functions appear as pretty colored bubbles and a bunch of icons on the Ribbon. It's easy enough even for Humanities professors to use on a daily basis, despite the fact that as a VCS, it's strictly inferior to something like git. Actually, I think it's popular precisely because it ain't git. Most professors who are fluent in Word's review functions would be hopelessly lost when faced with a Dropbox conflict, let alone merging git repos.