I think my post makes it pretty clear that I would. If you want, I could cite several examples of organizations which use the method I described, so you can weigh it against the one example you provided, and get the full picture.

In your example, for example, where was the issue tracked before the code was written? The format you linked makes it difficult to get the history of the issue.

Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task?

Git was built for email, because that's the system Linux uses. Commits appear inline. Diffs are reviewed and commented inline.

Email is the review process, and commits contain enough information that git blame can get you a reasoning - it doesn't require you checking the email archive. Rather than a dead ticket that no longer exists.

I can also supply you a list of companies that make use of git's builtin features if you like. But thats probably not relevant to discussing management techniques.

Everyone has its own system although companies do tend to codify it with a project manager. I used TODO.txt inside the repo. an org file, Things.app, a stack of papers, and a whiteboard. But once a task is done, I can summarize the context in a paragraph or two. That’s what I put in the commits.