I feel old because I can say that I have worked with most of the systems mentioned so far: I have a personal professional policy of spending the energy to get good at a given tool before I critique it. If I have not "gone deep" with tool X I'll say so.
1. Confluence - I agree that the search is horrid. It's got a couple of annoyances. For example I can't seem to make page anchors. If I make something a heading it gets an anchor but I want to make anchors in other places. The docs say you can but I haven't been able to get that to work. Also I've not done much semantic work in confluence.
2. Lotus Notes; that was a long time ago, I liked it, I don't recall there being any bog issue that kept me from getting the job done.
3. Mediawiki - my personal fav only because 1. OSS 2. plugable such that I can get neat semantic stuff to work. I use categories a lot, I use REDIRECT alot. I'm a firm believer in loose pluralism to start and rigorous lexicography as time passed. I love that I can do a stand alone server deploy of it, a two tier version, a containerized version, a cloud version, or a massive scaled out version. I love being able to do fancy semantic work in mediawiki. ( see
https://en.wikipedia.org/wiki/Semantic_wiki )
4. Post Lotus Notes and Pre-mediawiki, I lived in Word docs. It was technically less sex, and required what now seems to be clunky process, but it was functional: track changes, versioned files etc . I even wrote macros that would maintain change logs and version numbers for documents. There are obvious cross platform issues. But maybe a gsuite docs version might work?
5. I was able to operate with Sharepoint , but only barely. I asked very little of it, and it delivered. :P It seems like it encouraged complexity for no good reason.
6. I've also used Tettra, a commercial provider. It's very simplistic. If your needs are simple it might be for you. I managed my expectations and it hampered me still.
Another approach I have been toying is the "Documentation goes with code" approach. That is markdown files in code repos. Think README.md I like this. markdown is lightweight and easy to get. There can be duplication depending on application. Documentation about the software _where-ever_ you deploy it goes with the code. Documentation about how you have _specifically _ deployed it goes in the wiki. Operational lessons go in the wiki.
I'm notorious for putting a hockey stick in the "number of pages" graphs for a given company's knowledge base. Which is to say I make the count go up quickly. IMHO documentation is an operational responsibility, like keeping the server up. It's also the responsibility of the architect.
I'm also a strong proponent of organic growth but also "good curation". It should be easy for individuals to document as they desire. But the resulting "mess" should be curated, such that the plethora of view-points over time become a coherent, if dynamic, story.
The system should not be so complicated as to be a "barrier to entry". It should be easy to add new documents, and correct mistakes. It should be auditable. Depending on how serious you are about documentations it should also have good analytics. It should support multi-media reasonably. You should be able to search it well. It should support some type of "synonym" system . In mediawiki I use #REDIRECT alot. If you are using a slang term for something, Imma catch that and send you to the canonical name.
I've not used Dokuwiki.
David