I've been the sole committer on the TXR project, and have kept a detailed ChangeLog from quite early in the project. This is close to 11,000 lines long and growing:
(The commit messages in the repo are just a copy of what goes in the ChangeLog.)
[2016 edit: as of the mid-2015, I no longer maintain a ChangeLog file; however, the commit messages are written in a format which conforms to Git and ChangeLog conventions at the same time. The same level of detail is there, in a way that doesn't cause merge problems. A ChangeLog file could be mechanically reconstructed from these comments.]
Yes, more than once I've gone back to an old commit message associated with a change which broke something (uncovered with the help of
git bisect). The message helped me make sense of what I was doing.
In the ChangeLog you can tell when a function, type, macro or global variable was first introduced and when it was subsequently touched by changes.
But the main reason for writing detailed commit messages like these when working by yourself is this: you find bugs when doing this.
To write a detailed commit message has similar benefits to a code review of your commit by someone else. The value in a commit review is not so much that someone is checking your code, but that you have to explain your changes to another developer.
When you try to explain things, you sometimes find that they don't make sense.
Another reason: you can catch yourself making a useless change. By writing a detailed commit comment, you capture a high level view of what you are doing, and then sometimes you are confronted by the fact that it's not a good change.
I've sometimes made changes, when in the middle of writing the ChangeLog entry I realized that this was going to be a
git reset --hard (throw away these useless changes) rather than
git commit -a.