Earlier quoted context omitted.
I'm trying to cleanup a Git tree right now where people haven't put JIRA tags in their commit comments, it is impossible to find out why a change was made, it isn't a totally stupid requirement.
"It's impossible to find out why a change was made" is a completely separate issue. Either the code is documented or it's not, completely polluting your history with JIRA tags isn't the answer - not least of all because like a sibling commenter said you're now forever tied to JIRA, or if you ever move off of JIRA, now get to choose between bringing JIRA tag information into the new ticketing system, or rewriting your…
Commit message: "Improved clarity and detail in error message"
Ok, that's obvious what's happening, and as a standalone change that's absolutely fine. But the question it doesn't answer is why did someone actually put that effort in?
If the commit message mentions a ticket, then you can go look that up, and now you can find out, for example: it was a ticket that was an unknown bug being experienced by one specific customer, and so the error message was being improved as part of tracking down the bug. You also see who the customer was, internally who reported/escalated it, how long this has been an issue for, and if the bug was found and eventually fixed or not.
I'd argue absolutely none of that belongs in comments in the code, and it's way too onerous for a dev to constantly put that level of detail into every commit message. It's a balance: it's only useful to lookup that info on a small fraction of commits; it takes a lot of time to figure it out when missing (especially if it was many months ago); and putting a ticket number in each commit message is very low effort.