These are both things that every project ends up needing, but end up with some different solution, which then ends up with a loose, brittle, custom integration with the SCM - using your ticket name for branches, but the having to look up the details on a website - checkin hooks, these kinds of hacks.
It's not too difficult to imagine some simple, robust setup where the ticket state is and documentation (markdown) is store in the SCM, and you can view it either using the command-line, or fire up a local webserver embedded in the scm tool.
Everybody thought SCM had to be centralized too, until it turned out that it didn't. I can see the same benefits of making local changes to tickets and documentation, then sharing those changes later when they're in a good state.
With Mercurial and Fossil, they worked very intuitively for me.
Also, I like Fossil's tags. At work, I keep a repository of all the scripts I have written, and it really helps to associate individual commits with individual scripts.
(I mean, don't get me wrong, if you like Git, by all means, use it. But for my workflow, it is far too complex.)
Additionally, the fact that the bug tracker, wiki, and technotes/milestones are all distributed as part of the same database is very helpful.
Unversioned artifacts have been added recently, which are helpful for storing and optionally transmitting build artifacts associated with the repository.
No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream.
The code is simple and easy to modify -- I added tarball support (in addition to zip; but I think DRH rewrote the implementation that is in use) as well as S/MIME signing of commits (in addition to GPG -- to use X.509v3/PKI for more robust signing)
I'd guess that the majority of projects are small development teams and this is the point of Fossil -- it works well for small development teams.
When the Tcl developers were looking to migrate from Sourceforge to a new system, they picked Fossil over Git for a couple of reasons. Ease of use was one of them.
But forcing this approach precludes you of, for example, easily splitting your existing changes in two commits if required. If changes to the same file are to be committed separately, a non-zero amount of copy-pasting, resetting, temporary files, etc. will be required.
I see Git's separation of concerns of a strict superset for your use case. Just add an alias "git commit -a; git pull; git push".
You can turn autosync off in which case the fossil/git push/pull doesn't happen and your commit goes straight to the repository -- still without a staging area.
This is my personal usage but, if two changes to the same file are to be committed separately (e.g., git add -p) then the commit that should have happened for those separate changes that was tested just got missed, or the commit that is occurring is untested and perhaps incoherent. That is to say, I build my staging area out of files on disk at the same time rather than building a changeset that may have never actually existed on disk.