[tomxor]

> I have yet to see a project fail because commit messages were or were not in imperative form or if the first letter was capitalized.

This is probably unintentional - but i'm pretty sure this is a straw man - No one was implying not having commit message rules means project failure, but it might waste more time if they ever need to be reviewed by others or revisited in a git blame etc. Just like other project wide rules, it helps improve legibility and communication. However I find these rules to be few and general enough, well reasoned about to apply to any project.

I glanced at these years ago and just remembered them (50/72 + imperative mood, the remaining ones are just basic language stuff). I've never imposed them on anyone else but have recommended them, I mainly do it for myself (and I have benefited). The three I mention are the most important, the rest emerge from them (i.e imperative mood encourages you to talk about the effect, not just describe what the code already describes).

> There ar certain personality types that really enjoy organization and rules

I have similar disdain for excessive numbers of rules enforcement, but don't draw conclusions about how to utilise these. "rules" here, are just a way of formalising some principles that may help you write more useful and consumable commit messages - they do not have to be integrated into your org or project or whatever and enforced in order to be beneficial.