If you write good commit messages, you’ll read them when you come across them. Debugging a problematic commit is less painful when its commit message teleports you back in time to when it was written, and clearly expresses the intent of the change.
I absolutely do rely on commit messages, and ask for good ones during code review. Everybody on call needs to know how to find root causes in "git log" at 3 AM. The source can't serve the same purpose; including the complete history of what changed when and by whom would make it unreadable (especially things that used to be there but aren't now).
Somehow, in less than 2 decades, people forgot that there was life before git. Before commit messages became compulsory, we used to write comments right in the code. And that was fine.
They serve different purposes, and yeah, you can go without (either commit messages or comments, or even source code), but it just makes certain investigations more difficult, sometimes many times so.
Counter-anecdata: I read git history extremely frequently, across a variety of projects. Useless commit messages suck.
I do, but all I really need from the git is who, when, and a reference to a ticket. The code itself- combined with who wrote and when will generally tell me all I need to know. From there, a ticket will give me the any extra context might need.
But ticket systems are less stable than commit messages. Some companies decide to migrate to a new ticket system without migrating all the old "unnecessary" stuff.
That's just storing the information in a commit message in a separate database. Fine so long as you maintain the cross-links.