I can see arguments both ways. Having the wiki separate means that the repo doesn't get polluted with unrelated commits (especially important for SVN which doesn't have branches), and it makes setup at least somewhat easier, since an extra push-capable user doesn't need to be added.
Subversion doesn't have a built-in notion of branches in the same way that distributed systems do. Instead of being names for nodes in the DAG of commits, branches in Subversion are usually handled by manually maintaining separate versions of the same code in a branches/ subdirectory. In a distributed system, you could keep a wiki or bug database on its own branch, and commits to that branch wouldn't be visible if you only cared about the main branch. In Subversion, those commits would be visible, because it's all part of the same tree.
One caveat: Subversion's branch management may have changed since I last looked (version 1.5 or so). However, systems like Trac and RedMine were designed when branches worked as I described above, so it still serves to explain their rejection of SCM-backed storage.
