- We want well-curated content and want to keep hosted information intentionally "limited" to key documentation. (cf T290255: Workflow how to propose content changes)
- Wikis have a focus on a low-threshold contribution workflow ("Edit" tab etc). Compared to our "normal" wikis' edit rates and content, we do not expect a high rate of changes over time.
- We'd like to completely avoid vandalism if possible.
- Curation on a wiki might be possible via pretty restrictive edit permissions (or in addition FlaggedRevs but see T185664 about its problems).
- Seeing the API portal and its custom skin, I dare to say that making wikis look and behave like a mostly static site is not what wikis are designed for.
- We ideally seek a sense of ownership for listed content. Seeing e.g. WRC at https://meta.wikimedia.org/wiki/Wikimedia_Resource_Center , I am not convinced with regard to curation and active maintenance of content there. (Plus things like T169790 haven't happened.)
- Regarding well-curated content, we also want a certain level of standardization, machine-readability (see T276708: Define content storage format (levels, data structure, hierarchy, categorization, etc)), and translatability (not based on the Translate extension because T131516 is real, but preferably twn.net).
All of this makes me believe that MediaWiki is not the most suitable platform for a rather static Developer Portal site (cf. e.g. T67074#687573).
Thus we should explore other FOSS options, which, as a side effect, might also lower long-term maintenance costs.
(This may influence T261509: Sort out navigation concept to some extent, as MediaWiki skins also inevitably would.)