What I don't understand is why you would object to having more metadata attached to your commits. That is essentially what CCs are: additional metadata. Just like the author, date, Co-authored-by, Signed-off-by, and other trailers. It is information that can help you use your Git history in different ways.

You may find no use for this information, or find that it clutters the subject line, but I've addressed both arguments in my previous replies, and won't repeat it here.

> If I'm looking for a bug fix [...]

I mentioned a bug fix as an example, so I'm not sure why you're so focused on that.

CCs introduce a convention to how type and scope are specified. You're not required to use any of the proposed types, and should certainly come up with scopes that make sense for your code base. How you use that information is up to you, and I mentioned several ways that I've personally found it useful.

> The discipline of organizing commits is orthogonal to the discipline of labeling them.

I don't follow. You organize things by grouping them according to some criteria, and labels are required to uniquely identify those groups.

> One that is thoughtfully written by hand will naturally include the scope of the change any time that this concept is meaningful.

Ehm, sure, but CCs provide a framework that standardizes the way information is presented in a well structured repository. A scope is something most repos already use; i.e. it's common to see `<scope>: ...` in repos that don't follow CCs. Attaching a type of commit is another bit of information that further groups commits, and the notation `<type>(<scope>): ...` is just the suggested convention. Which, BTW, naturally came from the way some projects were already structuring their commits.