It's not the concept of a diff that baffles ordinary people. It's (a) the lack of an intuitive interface, and (b) poor integration with natural languages, that make most VCS's difficult to use in the context of a word processor.

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.

I liked what https://draftin.com did around version control.

'a bunch of lines removed/added' is a great representation for stuff that consist of semi-atomic lines, like code.

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.

I'd argue that it's not that great a representation for code, which should be diff'd syntactically.

You have the same problem with software.

FWIW, I don't often encounter diff output in my day-to-day computer usage, but when I do, I do not find them very intuitive to understand. A bit of UI magic would help here, it's not the concept that is hard (for me) to grasp, just all those lines with +'s and -'s and figuring out the contexts in which they apply. It's always a bit of a puzzle, especially if, for some reason, it's not highlighted with colours.

git is good here since it by default has colored diffs.