So you’re talking about SaaS / business tooling then? Again though, that’s just one of many segments of software, which was my point.
Also, even in that market it’s just not true to say that there’s no incentive for it to work well. If some new business tool gets deployed and the workforce has problems with it to the point of measurable inefficiency, of course that can lead to a different tool being chosen. It’s even pretty common practice for large companies to reach out to previous users of a given product through consultancy networks or whatever to assess viability before committing to anything.
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?