Honestly, I've worked with a few teams that use conventional commits, some even enforcing it through CI, and I don't think I've ever thought "damn, I'm glad we're doing this". Granted, all the teams I've been on were working on user facing products with rolling release where main always = prod, and there was zero need for auto-generating changelogs, or analyzing the git history in any way. In my experience, trying to roughly follow 1 feature / change per PR and then just squash-merging PRs to main is really just ... totally fine, if that's what you're doing.

I guess what I'm trying to say is that while conv commits are neat and all, the overhead really isn't really always worth it. If you're developing an SDK or OSS package and you need changelogs, sure. Other than that, really, what's the point?

Any standard that wastes valuable space in the first line of the commit is a hard sell. I don't see the point in including fix/feat/feat! just for the sake of "easy" semantic versioning because generally you know if the next release is going to be major or minor and patches are generally only only after specific bugs. Scanning the commits like this also puts way too much trust in people writing good commit messages which nobody ever seems to do.

Also, I fucking hate standards that use generic names like this. It's like they're declaring themselves the correct choice. Like "git flow".