> tracking changes, not documenting those changes
Documenting changes is part of tracking them. Yes, there is the code itself, but explaining those changes allows for following the development path. Do you expect everyone to read every line of code to understand every commit?
> commit-messages are just the bare minimum of ways to document
Single-line messages, yes. Multi-line commit messages are plenty for commit messages because they let you add more context about the changes.
I'd like to point out that it's possible for there to be multiple commits for a single issue - maybe the first one didn't fix it, or maybe there's multiple components being fixed. Simply pointing back to the issue won't give enough relevant information about each commit, it will simply say what the group of commits as a whole is supposed to do. If it turns out that fixing that issue caused others to occur, then the individual commit messages are going to be more useful for diagnosing the new problem than a single lump issue conversation will be.
I agree that there should be more documentation for a project than just git commits, I just think you're wildly estimating how useful commit messages really can be.