The thing conventional commits are really helpful for is continuous delivery. Every merge to main can be automatically tagged with semver and shipped because the thought that goes into tagging and versioning has already been done by the developers when they wrote the commit message.

I fully recognise that it doesn't make sense for huge projects like the Linux kernel to do this. But for 99% of projects conventional commits combined with semver vastly improves the release process status quo and makes it easy to automate.

I like relying on `git tags` even in continuous delivery situations. `git describe` is often good enough for continuous delivery versioning `v1.2.3-4-gabcdef` can describe a commit exactly enough to make git happy and is semver-like enough to set expectations, even/especially if new `git tags` are only ever inserted on human discretion (this is breaking change so I need to tag a new major now). The only real debate with `git describe` format version numbering is if to better conform to semver expectations the first dash should be a plus or not and you can do that change with a quick regex if you feel it is worth it for whatever is enforcing your semver expectations (ordering versions correctly in a package manager, for instance).

`git describe` is easy to automate for CD, but can leave version number decisions to people via `git tag` choices (and/or GitHub Releases) rather than trying to guess from commit history magic keywords.

I do this on my OSS projects to automate semver bumps and it's amazing! At work, I also enforce "tags" (not git tags, just strings in the PR title) based on who cares about the change and then generate changelogs for the respective teams based on those "tags".