This is from the author of SQLite, which I would say is pretty bloat free, so I would think that he has applied the same development style to Fossil.
I've stayed away from fossil as an SCM because it doesn't have the traction that others do (I personally prefer mercurial), but I have used it a few times where I needed a wiki and bug tracker, setup is about as simple as you can get.
The bloat in this case is not necessarily dependencies or size of code base. It's features, and compared to other VCS's that don't have a wiki, bug tracking, an entire web server etc on board by default.
The value of having tickets directly (which are fossil artifacts) be able to reference/link-to other artifacts (checkins, events, other tickets) is something that maybe needs to be tried to be fully appreciated. When repos are clones, all that info travels w/ the repository, so there's never a broken record of what's happened. The webserver is also really handy for interfacing the repo. It serves it's purpose well, and I personally wouldn't wish it away. Whether it's something as simple as an ad-hoc "fossil ui" to run the server and load a view into firefox for a quick glimpse at the timeline, or running it fulltime so a dev. team can get a better clue of their branching/merging, it's a nice feature.
I can see calling the wiki, and blog part of it bloat but bug tracking seems like a good thing to keep with the repo. If you are some where without network access, and you commit a bug fix you can update the bug tracker right then and there. No chance of forgetting to do it latter.
I've stayed away from fossil as an SCM because it doesn't have the traction that others do (I personally prefer mercurial), but I have used it a few times where I needed a wiki and bug tracker, setup is about as simple as you can get.