Выбор JIRA от Atlassian разумен, ибо является стандартом де-факто. Существует ещё и FogBugz от FogCreek, который позиционируется "более agile", однако не предоставляет native sidekick solution аля wiki и к нему нет такой тонны extensions.
Поскольку _реальной_ нативной интеграции между JIRA и Confluence НЕТ -- одни шалости, вроде возможности отображения issue listа по фильтру на странице -- причём это не попадает под versioning, так как является тагом. Итак, поскольку реального benefit использовать confluence вместе с JIRA нет, то со спокойной душой можно ставить любой другой wiki.
Позволю себе встрять в обсуждение :-) JIRA - оно, конечно, стандарт, но Вы реально пробовали кастомайзить там что-то более сложное, чем багтрекинг в софтовом проекте ? При попытке сделать шаг влево-вправо от опенсорсно-софтового проекта (не хочется клиентам все поля показывать, хочется _совсем_ другие workflow, хочется иерархию задач в несколько уровней) там все начинает трещать по швам и никакими плагинами оно не лечится. А вот это вообще перл, от разработчиков Confluence:
http://fishbowl.pastiche.org/2005/09/28/the_wall_of_death
Еще момент - а зачем знания хранить отдельно от багов ? И у того, и у другого есть workflow, они кем-то вносятся, кем-то изменяются, кто-то должен получать notification-ы, кто-то должен настраивать права ? Зачем все делать дважды в 2-х системах, а потом заниматься их интегрированием ?
Думаю, путем интегрирования вышеописанных продуктов проблему не решить, развалится оно все. Надо либо что-то свое писать, либо смотреть в сторону более гибких систем, типа IBM ClearQuest, TrackStudio Enterprise, Serena TeamTrack.