A git commit gives you the reason for the change and the context of what other files were changed at the same time. I’ve found that invaluable.
Have you heard "have you played guitar for 20 years, or have you played guitar 20 times for a year?" Time only helps with accumulating wisdom if you let it.
TL;DR: "never have encountered in 5 years" is a meaningless data point.
My professional career can legally drink beer since a few years back, yet I'm still regularly hitting "first times" on various things in my day job; I'm also frequently mind-blown reading about others' experiences in domains I never touched. Don't make those "5 years" into a badge to hide behind; use it as a springboard to reach higher.
In this case, try to actively think of uses for the commit history. It's already there; there's an expectation (admittedly, to various degrees depending on context) that it will be maintained. Try to maximize the value you get out of it. Underutilizing a tool you have access to may not be that much of a problem on average, but in some specific circumstances can make a difference between being able to complete a task at all or not. You shouldn't rely on luck to never land in a situation like that: familiarizing yourself with as many potential uses for a tool as possible gives you a better chance of handling it more easily.
EDIT: formatting, last paragraph.
On a large project it's probably the first tool I reach for when we find something we have reason to believe was a recently introduced bug. Specifically annotating (git blame) the relevant code and scanning for what lines have been recently modified.
I've worked in startups where there were only 2 backend devs and a frontend guy. There it was almost completely irrelevant and I spent a couple of years at a large software shop, early in my career, where bugs in production code was mostly someone else's problem.
FTFY ;) I broadly agree, but it's important to note that, in practice, Git commits are hit and miss: they might save you a lot of time if they are well-structured and described properly, but they might also completely fail to give you anything of value (for the problem you're facing at the moment). Turning Git history into a broadly useful artifact requires a lot of discipline from everyone working on a codebase over its lifetime.
It's never totally useless, but it's often less helpful than it could be.
Recently, I turned to JJ for this exact reason: crafting a meaningful change history is much easier there, especially if you need to retrofit it after you're done with the implementation. jj's split, squash, and describe are a joy to work with, also because the interactive version lets you easily split or squash hunks (selected changes in the same file).