Having had a lifetime (at least since age 10) in IT and SW and having coded blog engines and portals over the years, I'll pick up on some of William's comments, which is a stretch to class them as 'truths'.
1) Don't code. It has all been done already and more. Do not need to reinvent the wheel and better ways to spend energy.
If no-one coded, there would be no software for us to use, no plugins/tools/addons to existing packages in order to allow 'front-end' users like yourself to add the specific features that you require. The Fundamental Process dictates that we will always re-invent the wheel somewhat - but thankfully we are as a species learning from our mistakes, hence the plethora of Frameworks available to ensure we now start from a consistent foundation.
2) Use the same thing to do other things, be composable (e.g. fractal). Avoid domain specific directions when ever possible. Don't use a wiki for this, a blog for this, custom code for that. It is confusing and tedious for the users and admins. There is enough ability in the modern day free blog stuff to cover almost any use case. Once user is used to a format and display, the user wants to stay there and not be redirected to another toolset or UI.
I agree to a certain degree. But there comes a point where your one-fits-all package is no longer suitable as a delivery mechanism for the results you wish to achieve. A blog is certainly useful as a blog, and they have many, many (coded) plugins to add functionality. But few blog packages were written with the foresight for todays flexibility needs, and they are a mish-mash of fixes to try and meet the changing demands. Thankfully the current wave of blog engines are built upon the foundations of the recent forward-thinking Frameworks.
2) Videos. A video is then just another blog post with a discussion thread under it.
Unfortunately this isn't the case. A video will contain a number of questions and answers, which certainly can be discussed in the comments (as is already done on YouTube), but it does not pull the data out in a suitable format. For someone to find comments related to a particular question would very quickly become tedious. Even forums like this one are tedious when having to read through various off-topic discussions after clicking on a thread title. What is currently needed is the separation of questions where the same video will appear in the content of each question related to it.
3) Post ratings. Users rate replies or posts with 1-5 stars. The community determines what is good or worth taking another read on. Feature in many blog engines already.
In blogs this is a desirable feature but not for current MBT data-mining. What is needed initially is the 'official' answers not community popularity, hence Ted's earlier comment in regard to removing the voting of comments. (Some voting can be useful, such as Spam voting to remove a comment from the thread without the need for individual moderation, but this feature also gets abused where users will down-vote comments they disagree with.)
4) QA. A Question is really just another blog topic tagged with "Question". Answers flow below it as normal and can be rated (or not).
Again, this is not the case. Ultimately the Question, the Answer(s) and the community Discussion need to appear
on screen to be a seamless page related to the question, but to allow the greatest flexibility when we do not know the best approach to take we initially need to separate the Q's, A's, D's and Tags in the back-end database.
For this reason I believe that the use of dedicated Q&A software at this time provides the most flexibility. The Form plugins for MediaWiki would provide the ability to enter data in a consistent format, but the data is then coded within the body of the wiki page, which makes it more difficult to extract individual elements at a later date - it would be a manual process to a large degree rather than an automated one. For the same reason a Blog is not IMHO the best storage system for the Q&As.
Presentation of the individual systems (Wiki, Forum, Q&A, etc.) for users to feel confident in using the website(s) comes down to front-end design, single-sign-on, consistency of terminology, consistency of links, consistency of layout, etc. I completely agree that each time you add a new system you are also adding the overhead of creating this consistency, but therein lies the balance that must be found between usability and suitability.