Git, in spite of the horrifically complex interface, is in essence a really dumb version control system (I mean that in a non-insulting way). This means it's fairly neutral about what kinds of data you can throw into version control. And more importantly, it almost never complains about what you give it.
I think that's why people are now starting to think about applying version control to domains outside of code and choosing Git to do it. For example, I had an idea a few years ago to make a CMS on top of Subversion as the data store (never got around to building it though). Now there are lots of projects like that built on top of Git: CMS, Wikis, you name it. Generally anything that can work off flat files is very easily converted to use Git as a back-end, giving you advanced version control features more or less for free.
From a practical perspective, the difference is not just that Git is a trendy new silver bullet, it's the "dumbness" that makes it actually easier to do that kind of work than it would be on older version control systems like SVN. Interestingly, for the most part, most of these projects do not really benefit from the distributed nature of Git (although for things like wikis and CMSs it can offer yet another feature: content migration between instances). It's more about the ease of use for getting data into a repository and under version control without it exploding when something unexpected happens, like a file getting renamed.
You might not get the best front-end experience for actually doing stuff with that version history (as other comments have noted wrt diff tools, etc., which tend to be geared towards code rather than other types of content) but that's the fault of those tools rather than Git (which is dumb enough not to care about content types), so it's just a question of incrementally building up a better toolset for your particular content domain. That's much easier to do and more approachable than building the whole infrastructure from scratch.
As for Github, it happens to have a nice interface, toolset, documentation and mindshare. Developers are familiar and comfortable with it, so there's no need to research and learn "yet another tool". And because it's cloud based, you can get up and running very quickly without worrying about hosting, etc. That's just more icing on the cake really.
I think that's why people are now starting to think about applying version control to domains outside of code and choosing Git to do it. For example, I had an idea a few years ago to make a CMS on top of Subversion as the data store (never got around to building it though). Now there are lots of projects like that built on top of Git: CMS, Wikis, you name it. Generally anything that can work off flat files is very easily converted to use Git as a back-end, giving you advanced version control features more or less for free.
From a practical perspective, the difference is not just that Git is a trendy new silver bullet, it's the "dumbness" that makes it actually easier to do that kind of work than it would be on older version control systems like SVN. Interestingly, for the most part, most of these projects do not really benefit from the distributed nature of Git (although for things like wikis and CMSs it can offer yet another feature: content migration between instances). It's more about the ease of use for getting data into a repository and under version control without it exploding when something unexpected happens, like a file getting renamed.
You might not get the best front-end experience for actually doing stuff with that version history (as other comments have noted wrt diff tools, etc., which tend to be geared towards code rather than other types of content) but that's the fault of those tools rather than Git (which is dumb enough not to care about content types), so it's just a question of incrementally building up a better toolset for your particular content domain. That's much easier to do and more approachable than building the whole infrastructure from scratch.
As for Github, it happens to have a nice interface, toolset, documentation and mindshare. Developers are familiar and comfortable with it, so there's no need to research and learn "yet another tool". And because it's cloud based, you can get up and running very quickly without worrying about hosting, etc. That's just more icing on the cake really.