The tree-based approach to organizing documentation sucks

Documentation sucks because it's hard/impossible to do well. Every change to the code can trigger cascading changes in documentation and there's no compiler to tell you which things need to change.

Wiki linking, in that case, is just an alternative way to duplicate the content of a page on the tree. Other methods include redirects and using software that can symlink individual blocks of text to keep them in sync.

As to why documentation is bad, it's because people close to a project are not in a good position to communicate about it. Absent a large, self-documenting community, the best solution is to either have documentation be done by an employee who is a power user or customer of the system, who writes well, or by taking developers off production duty to do nothing but provide support to users and structure them into general answers and explanations.

Wiki just on itself, where you need to browse inside to get where you need won't work. Now you need to find the right node in the graph that connects to your information.

I feel the same way about Stack Overflow. I rarely search for the answer to my question inside SO, instead google takes me to the relevant page.

So what companies seem to need is documentation in any format, hierarchy or graph, plus a really, really good search engine over it.

The OP actually tells that story exactly. They love writing answers in slack precisely because they are ephemeral and targetted at a specific immediate need (which also makes it a lot easier than writing general-purpose documentation btw). But the persistent documentation "just decayed and eventually nobody used it." Exactly.

It's possible the right tools can make it easier to maintain (and thereby less likely to go out of date), but I don't think just simply taking a graph approach is sufficient or a very significant part of it. I'm not sure what that would be -- one obvious answer is tools that generate docs from code or otherwise tie it to code in such a way that when the code changes the docs are forced to change. But while that makes sense, every attempt at this I have seen results in disastrously unfriendly documentation (see eg "relish").

Other approaches are just to capture all that "answer the ephemeral question" documentation that is happening anyway in a way that makes it persistent and more easily searchable. A sort of "knowledge base" approach. (which, true, isn't tree-based). Some of the answers will be out of date when you find them later, but that is expected which somehow makes it less disruptive, and it's still better than nothing.