I found maintaining a good documentation inside a wiki tough. People (including me) will tend to create new pages willy nilly, never deleting old ones. The layout is generally rough, you generally have a basic structure, but under that, you see a mess of pages at every levels. The information is often out of date and often redudant which creates noise even if you have quality pages (and even if you have a good search).

The plus side of a wiki is its accessibility. Committing a text file inside a git repository is a tough ask to none technical people. Asking them to "fork" and do a pull request is even harder.

But to maintain quality documentation inside a wiki, a dedicated curator is almost always needed.

It's also not in or near the logical path of code/product changes. You need to login into a dedicated system, find the page you need to change or where to add a new page and finally do the edit. It's kind of hard to have a systematic good documentation in such circumstances. Also, doing reviews and documentation versioning (in sync with product versions) is kind of hard with a wiki.

For all these reasons, I tend to prefer putting my documentation right next to my code in a markup language (simple Markdown README.md for simple projects, RST+read the doc for more complex ones, but that's a personal preference). You have far more incentive to edit the documentation, versioning is automatic, documentation versions are in sync with your product versions, review is easier (just include it inside the PR, same as code review).

The downside is less outside accessibility. It's also a very "low altitude" documentation, great for documenting individual libraries or components, it's not so great for things like documenting overall system architecture, or organizational stuff like processes, basically anything not tied to one specific component.

In the end, wikis have their role, but I found they are generally overused and miss-managed.