Well, this is going to be very offoptic, so please bear with me, anyway:
I don't disagree that, in a perfect world, things would be the way you say - in reality however, it's not such a "black and white" thing unfortunately.
Equally, like I recently said in another topic, there would be no need for unfinished, outdated and especially quote-based wiki "articles" if people implementing new features would also write the corresponding documentation (think the Nasal flightplan APIs).
That being said, I have contributed to the wiki long before it was "official", and long before it was used by "the team", i.e. back when it was actually used primarily by other contributors interested in helping document things, and that included adding, and often also writing, documentation that simply existed nowhere else, or "documentation" and "advice" that was only provided in the form of discussions on the devel/users mailing lists.
None of this is to say that I disagree with any of what you said, but I don't see it as a clear-cut thing unfortunately - which would be hugely different if the people implementing features would also automatically document them, even if just in the form of corresponding "*.README" files in $FG_ROOT/Docs (which was the predominant practice in the early days of the project).
However, that is no longer the case, and it took basically the better part of a decade for the project (well, some of the team) to actually "adopt" an issue tracking system and a modern SCM - with this context in mind, it does make sense to use the wiki in this way, because it simply works. Without doubt it would be better to organize the wiki accordingly, but that is not a difficult thing to do, and it can even be done by people not interested in helping write/maintain the wiki. So, feel free to "be the change you want to see". Categories, and even portals, are "cheap" to do after all.
But again, this discussion is very much offtopic, and we've had this discussion more than once, "cleaning up" the wiki to move unfinished articles to a different category is not exactly rocket science either. it's just not something that I am currently prioritzing, and certainly it also isn't something that I am going to prioritize as long as I find myself having to add information to the wiki that would otherwise be lost in the depths of the archives, because the people implementing new functionality don't have the time, or the inclination, to add dedicated docs.
Thus, this is more of a chicken/egg issue than most people realize: The wiki could certainly be in a much better shape if people were documenting their efforts, especially finished features, much better - no matter if that means using the wiki or not. Using its state as a mere excuse for not getting involved in documenting new, or recent, additions is very much pathetic at best, especially in the light of the project's tradition to commit dedicated feature.README files to $FG_ROOT/Docs pretty much since the beginning of the project.
And to be honest, I'd rather not have this discussion here and now, because there's nothing that I fundamentally disagree with, I am well aware of the general standpoint, but as long as there is such an enormous disparity between documented and undocumented features/contributions, without anybody willing to do something about this, I am seeing a need for a workaround, even if it's a poor substitute for proper documentation.
Ultimately, it all boils down to trying to be a part of the solution rather than the problem - as someone who's literally spent hundreds of hours adding relevant contents to the wiki to cover features that would otherwise not be documented anywhere, I feel that my perspective is more than justified. Nevertheless, I am certainly not going to write proper articles for each and every undocumented/updated feature that I am aware of. What I am doing, and how I am doing it, is a feasible compromise without causing tons of work, and that includes adding contents that cover discussions or work-in-progress features. Not because I think it's such a great idea, or experience, to do so - but because I actually saw, and am seeing, it work out reasonably well, given a sane time frame.
Obviously, YMMV - but this whole project being a community driven project, it is obviously up to you (and everybody else) to disagree with developments, features and also documentation/articles and provide a compelling alternative, i.e. something that just turns out to be much "better". At that point, what will usually happen subsequently is that your contribution is superior, and going to help deprecate/phase out the legacy contribution.
As a matter of fact, many of the most compelling features, including some aircraft/cockpits, came to be due to a certain degree of "disagreement" with the way someone else handled something, I think we're all aware of the history of the shuttle effort, and the irritation that caused at some point - yet, we're once again seeing "survival of the fittest".
In other words, if you -or anybody else- should come up with something "better", please be my guest, and I'll actually applaud any efforts to remove quote-based articles and/or articles merely covering proposals. But for the time being, I ain't see that happening (unfortunately).