I think a big driver here is "ecosystem of tools" and "simplicity of forks". Git tools are increasingly ubiquitous and easy to find. While a good Wiki engine has a concept of document versioning it can vary from Wiki system to Wiki system, whereas the git repository history logs and annotation tools are well standardized and provide multiple choices of options of tools to browse such things (both programmer-centric and some more "friendlier" tools). You can edit the git repository online in Github and the tooling isn't all that different in experience from a Wiki to a less technical contributor, whereas a technical contributor can also grab the git repository using a tool of their choice, edit in a friendly environment (IDE/emacs/vim/etc) of their choice.
Simplicity to fork can also be important, and beyond just the Github-provide "fork" option, but in general of push/pull communication between "wikis". Wikis typically are stored in bespoke database schemas and import/export from and between them can be a pain. Git is entirely built around (programmer) collaboration and has protocols for pushing/pulling between repositories. This can make it easy to fork repositories, of course. (Compare to, for example, the Wikipedia world where when sections are "shut down" just about the only well clustered option to preserve them is often Wikia with its somewhat complicated import process of the peculiar MediaWiki XML format and some use of mostly documented public APIs. For smaller Wiki engines than MediaWiki sometimes the only way to migrate data is a raw database dump.)
Further more, at the intersection of "ecosystem of tools" and "simplicity to fork", a wiki like this on Github is "just a folder with a bunch of Markdown files". Push it to Github and Github builds all your Markdown for you and displays it (and allows you to edit it) in a nice, easy way. Push it to Bitbucket or Visual Studio Team Services or Gitlab or any number of other providers and you get much the same web-based view. You get some choice there between definite competitors. You could add a table of contents and turn it into a Gitbook or Leanpub book (and other less well known competitors in the book from a git-backed folder of Markdown files space). Furthermore, you can always just grab the git repository locally and build the Markdown yourself (again, using any number of command line tool options or IDEs that you prefer to use).