I view it quite differently. Like TSDoc for TypeScript or Ruby-Doc for Ruby, there's Sphinx for Python. Using a general-purpose static site generator for Python docs feels just wrong, like you wouldn't use Wix instead of rustdoc for a Rust crate... But maybe that's just me.
> I used Sphinx for years, but mkdocs produces far better docs. Especially when combined with mkdocs-material.
IMO humans write the docs, not Sphinx or mkdocs, and human approach is what ultimately determines whether the docs are good. From this perspective Textual can absolutely have good docs, and especially since they mentioned Django as the inspiration I'm reasonably sure they will.
However, the use of documentation builder can affect how easy it is to achieve certain niceties: Sphinx with autodoc, for example, offers direct links from docs to implementation and cross-package document linking. The builder can introduce useful syntax sugar and salt: Sphinx+RST, for example, subtly encourages proper "rich" linking to actual Python units rather than using dumb identifiers everywhere (see single backtick behavior in RST vs. Markdown), which in turn forces you to write better docs (you must document units you want to cross-reference or you'll see warnings during doc generation) and think about structuring API in a way that makes it easier to document and maintain that documentation.
(On that note, I haven't seen a project anything that paralleled Django documentation by all metrics, and that one is built using Sphinx.)
So while the docs can be great regardless the choice of a build system in case of Textual IMO still breaks the familiarity pattern for Python documentation readers and contributors, breaks interoperability within Python ecosystem (no links to source or to/from third-party packages), and goes with a more limited markup language than RST for no obvious (to me) reason.