The biggest weakness with ExDoc is oddly also one of it's greatest strengths: that the documentation is fairly tightly coupled with the code. Insofar as we're using the documentation as a reference for things like function explanations, this approach (unsurprisingly) works pretty well. But the way we structure our code across applications, modules, and functions for various technical or code quality reasons isn't the best way to build it's documentation.
For example, recently I've been learning the Phoenix Framework. For the framework to be both flexible and also so that the code is well organized, it's been coded across different Elixir projects: there's "phoenix", "phoenix_live_view", "phoenix_html", "phoenix_ecto", (etc). This division is absolutely appropriate, but it does mean that to do anything useful with the Phoenix Framework you're pretty certainly going to use a number of these different Elixir projects. But there's nowhere for the documentation to weave together the master plan of these different modules, the bigger ideas and concepts to exist. The most basic unit of documentation is the individual component and so when a real understanding how the components fit together is needed, there's no obvious place for that to live and often times you end up context switching between different sets of documentation.
Don't read this as ExDoc should account for this, but that it's easy to see ExDoc as the only documentation tool when often times complete documentation of complex projects requires something more.