Integrating those systems directly into Fossil seems like a poor design decision. Everyone has different requirements and it directs focus away from the core responsibility of a VCS. Do one thing well and all that good stuff.
Yes, if you narrowly define VCS as "shoves code around". If you define it as "versioning the code and related project material" then it's exactly what should be in the tool. In fact, I predict this will be the next iteration of project management tools, where everything is stored and managed in git/hg/mercurial, so the next logical step is what fossil does.
People said that same sort of thing about RoR or Django too. "What?! You have to do it the way they want? I prefer fooORM!", and so on. The point is not that it is great at whatever, the point is it get stuff out of the way at start time, and allow you to get to the meat of it quickly. Later on if the project turns into something interesting, you can switch to redmine, or put a real wiki behind it, and so on (but only as really needed).
That's an interesting point in light of Rails' recent movement towards more modularity. It suggests that there may be room for a Fossil-like abstraction over Git that has (pluggable?) built-in cloned-by-default issues, wiki, etc.
Honestly I've always wondered why redmine, trac, et al don't already build their wiki on top of the vcs anyway, instead of using a separate database with tracking. Such a step seems counter-productive.
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.
