Там описывается принцип работы, устройство, меры предосторожности, история создания - эта информация может дополняться деталями, уточнятся, но даже в таком виде она будет верна еще лет 10 точно. С течением времени не изменяются принципы работы микроволновок, даты исторических событий, списки произведений писателей. Если на какой-то вопрос единого мнения нет (межнациональные конфликты) - скорее всего появится несколько статей от каждой из сторон с минимальными исправлениями после написания.

Но ведь в корпоративных wiki никто не собирается хранить историю развития компании или биографию руководителей - это средство позиционируется для документирования проектов/продуктов, которые сейчас находятся в разработке/работе и постоянно меняются. Т.е. я могу написать детальную статью про то, как у нас работает генератор отчетов, но кто будет ее править при каждом изменении подсистемы кеширования или форматов вывода даты/времени ? Меня периодически ставит в тупик куда более простая задача - вот мы тут чуть подправили это,  что теперь нужно перетестировать и какие скриншоты переснимать. Если я не знаю всю документацию и все скриншоты - я эту задачу решу только полным перебором, а если знаю - зачем мне wiki ?

По опыту работы: если разработчик что-то меняет в TrackStudio 3.5, то хорошо, если он аналогичную правку и в 4.0 сразу и правильно сделает. Про то, чтоб проверить пользовательскую документацию (а вдруг у нас там какой-нибудь скрипт из примеров отвалится) или перечитывать документы в духе "а как у нас генератор отчетов работает" и речи не идет. Если программист про существование описания работы генератора отчетов не знает - он его и проверять не полезет. После наступания пару раз на грабли типа "в wiki одно, а в коде - совсем другое" доверие к документации резко падает, ее даже читать перестают, не то что писать.

Второй важный момент: когда пишется документация, то важно понимать для кого именно она пишется, и как он ее будет использовать. Статьи энциклопедического плана ("как работает генератор отчетов", "как настроен Subversion", "что означают кнопки на странице Task") тут не годятся - нужны статьи, описывающие _действия_ конкретных людей в конкретных ситуациях ("как написать еще один отчет", "как вытащить исходник из subversion", "как создать/удалить задачу").

У нас есть один замечательный документ 2000 года под названием "Как у нас устроен CVS репозитарий" в котором на 3-х страницах описано на каких серверах что запущено, в какие конфиги что прописывалось при настройке, и как оно все работает. Теоретически, дока была бы полезна для админа, который настроил CVS, после этого отформатировал диск и хочет повторить процесс :-)
У нас такого админа не нашлось, мы уже года 3 назад переехали на Subversion, а про наличие этой доки вспомнили буквально несколько месяцев назад во время ревизии документации. Почему о ней все забыли ? Да никому не интересно, как у нас устроен CVS репозитарий, хотя пошаговые инструкции "как подключится к нашему репозитарию" и "как быстро настроить репозитарий для тестирования интеграции" были бы полезны.

Энциклопедии - это ведь развлекательная литература, они годятся для расширения кругозора, но не помогут, если нужно что-то конкретное. Скажем, та статья о микроволновках какое-то представление о них дает, почитать интересно. Но
- если я хочу купить микроволновку - мне нужна информация по производителям, характеристикам, ценам, наличии, условиям доставки.
- если я хочу собрать микроволновку - мне нужна принципиальная схема, информация о деталях и их производителях.
- если я хочу приготовить что-то в микроволновке - мне нужны рецепты.
и т.п.

Т.е. для любого конкретного применения этой энциклопедической статьи будет мало. Более того, если я захочу купить/собрать/приготовить - изучение этой статьи будет напрасной тратой времени, лучше сразу искать более специализированные источники. Если же дописать эту статью, то поддерживать ее в актуальном состоянии  станет просто невыполнимой задачей.

Возвращаясь к корпоративным wiki, я не вижу их преимуществ перед CMS (типа Drupal) или ECM (типа Alfresco). Больше всего мне не нравится дураций язык разметки, совсем обычным пользователям понятнее Word, а IT-шникам - подмножество HTML.
Еще одна важная группа пользователей - переводчики. В большинстве своем они освоили тэгированные форматы и не пытаются переводить HTML-тэги, а системы translation memory хорошо понимают word, HTML и форматы издательских систем. Но разметку wiki практически никто не знает, софтом она не поддерживается, про зависимость форматирования от количества вставленных пробелов молчу, со времен Clarion такого "чуда" не видел.
Тогда зачем все это ?
Защита от вандалов ? Для корпоративных систем это не очень актуально.
Возможность коллективного творчества ? Практически не используется.

Да, знания внутри организации надо накапливать и систематизировать, но ведь энциклопедии все равно не получится, а для всего остального wiki - не лучший формат.