There's no benefit to any of this. Just write like human. It will be clear if it's a fix, or a refactor, or ?. Typically it isn't just one of those things.
Making an opinionated absolute statement about something that's widely used and argued about isn't even logical. If nobody got any benefit, it wouldn't be a thing.
The CC standard may not be for everyone, but having some convention is often helpful. git log --pretty=oneline of structured format gives you broad filtering that's useful. Just writing like a human doesn't give you that ability and you're forced to read every line.
I gave an example right there in my previous comment (log filtering). To expand: our eyes and brains are good at pattern matching. Looking at git log --pretty=oneline with a structure lets you discard any commits irrelevant to what you're looking for without much cognitive effort (e.g. if I'm interested in a code change, I can discard any commit that starts with "docs"). You don't have to read entire lines, only scan the first few characters, or have grep do it for you.
Another example is basic metrics stored right there in git. Did changing your testing strategy result in less follow up fixes after feature deployment? You can get that signal with a shell | pipe one-liner.
Honestly I'm not die-hard CC convention, but I think it's better than nothing, which is what the person I was responding to was suggesting. If you're using an issue tracker, having a convention to prefix or trailer the commit with the issue ID is the highest value IMHO. The point is having some convention to get teams on the same page and assist with git meta work.
The CC standard may not be for everyone, but having some convention is often helpful. git log --pretty=oneline of structured format gives you broad filtering that's useful. Just writing like a human doesn't give you that ability and you're forced to read every line.