When I'm evaluating an open-source project, I always check the quality of its commit messages. I don't care about following a specific format or something, all that matters is whether they are informative or not.
Hello, I am the creator of the Odin programming language, and main architect of the codebase too. Being full of commits labelled "Fix <thing>" is absolutely fine and absolutely clear with all of the context of how the codebase operates.
Many of the things are "Fix #NNN` which means fixing a specific GitHub issue which usually has more information to it or has comments in the code, etc. There are many "Fix typo(s)" commits because I (and others) make a lot of typos; these are usually trivial/single-line fixes. Then it comes to the rest of "Fix ..." commits which are pretty much 1-2 line fixes of minor bugs; with large bugs having multi-line commit messages and many with huge comments within the code to explain everything.
Your metric of the quality of commit messages is not a bad one depending on the codebase, but it cannot be used blindly without knowing how that codebase operates. Especially comparing a mostly centralized codebases (like Odin) to very GNU-style decentralized codebases (all of the examples you gave).
Naturally, commit messages aren't the only criteria I'm using. But I wasted way too much time in my life on deciphering the purpose of 20+ year old commits to ignore this.
When I want to discard the opinions of HN commenters I always go for tired, worn-out references that I don’t even understand myself.
A commit message has a function which is directly applicable to the craft of programming and not something auxiliary like the aesthetic properties of a shed used by the bicycle commuters. Though in this case I would disagree with the GP since “Fix <thing>” might be a good enough commit message template.
How many developers are there? For single developer projects, commit messages have very little value compared to documentation and an extensive passing test suite.
As the project grows in contributors, the commit log gains value
According to GitHub, there are 132 contributors. Probably most of them were one-off drive-by PRs, but nonetheless, it's definitely not a one person project anymore.
Even if you're a solo dev, you will likely still have to debug your old code in the future. I'm sure most of HN is familiar with the Chesterton's fence. Proper commit messages aid you in understanding why the changes were made. This especially matters in complex codebases, like compilers.
Many of the things are "Fix #NNN` which means fixing a specific GitHub issue which usually has more information to it or has comments in the code, etc. There are many "Fix typo(s)" commits because I (and others) make a lot of typos; these are usually trivial/single-line fixes. Then it comes to the rest of "Fix ..." commits which are pretty much 1-2 line fixes of minor bugs; with large bugs having multi-line commit messages and many with huge comments within the code to explain everything.
Your metric of the quality of commit messages is not a bad one depending on the codebase, but it cannot be used blindly without knowing how that codebase operates. Especially comparing a mostly centralized codebases (like Odin) to very GNU-style decentralized codebases (all of the examples you gave).