It sounds like you are documenting too much trivia in the wiki.
Document blocks of code and methods in the code. Try to make your code self-documenting so you don't have to make a lot of comments. Writing unit tests can help too.
Document design decisions and architecture at higher granularity in the wiki so the wiki doesn't need to change often or take a lot of work to change. If a lot of people on your team already know the architecture and the team is not growing rapidly then there may not be a strong case for documenting them at all, face-to-face is often the best knowledge transfer.
Rewrite or delete out-of-date information immediately, like dead-code the longer it remains the harder it becomes to spot and the more of it accumulates. If you don't have time just delete it and mark the article as needing rework, it slows you down and is stored in version control anyway.
Document procedures by automating them in a script or installation file. Otherwise keep them in the wiki, but every time someone uses a procedure from the wiki, tell them to try to improve the article or automate parts of the process.
Blog articles belong in blogs. If people want to share their personal opinions and advice create a company blog for that. They probably don't want their articles to be modified and no one will modify them anyway, so don't let them clutter up the wiki.
Adhering to the recommended guidance to exclude assumptions from a functional requirement document depend on a few things.
First, how strict is the culture and the project?
Sometimes recommended practices are treated as defacto required practices. It is 'good practice' to ensure how strongly such things are merely recommended, and which are in practice, required. Endeavour to have some idea what any consequences might consist of if you do or do not adhere to the 'guidance'. That is my disclaimer.
Second, what is the rationale behind the guidance?
So what might be the rationale for steering functional requirements document preparers and contributors away from including a section devoted to assumptions?
In my experience, people and projects view functional requirements differently at times. In some cases, functional requirements (what happens and sequencing or when something happens) are clearly distinct from system or service requirements (where or how something happens). Finding the distinction when the system or environment is central to the effort (device or service interfaces or device drivers, for example) may prove to be more effort than it's worth, and so in those cases I would state that as my first assumption and then move forward.
In the case of the functional requirements document, the rationale for not including an assumptions section may be presumed that if a section for assumptions feels required, then perhaps the requirements are not functional. In other words, if you feel that there are relevant assumptions that should be documented pertaining to the included requirements; the requirement may be too specific to an implementation or a particular service, and perhaps do not belong in that particular document. On the other hand, maybe the requirements do belong but just rewritten in a different manner as to not be so specific that a particular implementation and related assumptions would then cease to apply. It is probably intended that the guidance is not a prohibition, but rather as a sanity check or an orange flag to the document preparers and contributors.
If I were to approach a functional requirements document in the strictest sense, system and service requirements would not appear there. If those types of requirements are not included within the functional spec, it is lot less likely that you would need to make or declare any sort of global assumptions (often pertaining to the environment or user). If you find that global assumptions start applying to the requirements being included, it may indicate the requirements are not written as functional requirements, or that the environment or user are central to the effort.
Best Answer
It sounds like you're making the assumption that the documentation is written once and never updated. That may be true if your software never changes after it has been written, but that's probably not the case. Just like you can refactor your code to improve readability and maintainability, your documentation should also be in a format the promotes the ability to refactor. Your initial code authors are good candidates to write the initial documentation, but the people who maintain the code will also need to maintain the documentation. If the existing authors are still around and are answering questions from the new maintainers, someone (either the original authors or the new maintainers) should be assigned the task of making sure that the documentation is more complete.
The exact breakdown of roles and responsibilities depends on the organization. In some places, the developers are responsible for anything in the code file (API documentation and in-line comments) and the developers and testers support technical writers who write and maintain documents. In other organizations, the development team may write everything.
At the end of the day, it doesn't really matter who writes and maintains the documentation, as long as it is maintained. After all, wrong documentation is quite possibly worse than not having documentation at all.