I'd recommend following the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) guidelines for writing the commit messages.
- The kernel patch descriptions: https://kernelnewbies.org/PatchPhilosophy. Used by the repository that Git was created for (the Linux kernel) and Git itself;
- Gitmoji: https://gitmoji.dev/, similar to conventional commits but using emoji
Personally we may like them or not. But again, even though I don't like it, I would a history with "<bug emoji>: do foo in bar" instead of a history with a lot of commits only named "fix", "now it works" and things like that.
> Personally we may like them or not. But again, even though I don't like it, I would a history with "<bug emoji>: do foo in bar" instead of a history with a lot of commits only named "fix", "now it works" and things like that.
It is good to have standards which will disqualify low-quality commit messages.
Git trailers are neat, but ultimately suffer from a UI issue: most people are using interfaces to git that don't use the plumbing, and they put all the important info in the first line (and sometimes have a frustrating cutoff of 50 characters) and git trailers are considered a remnant that gets no special handling (if you're lucky, the Co-Authored-By trailer has special handling, but that's about it).
If you're trying to quickly conceptualize why the history of a file is the way it is, then being somewhat consistent with scope labeling helps a lot.
In practice, the style will just be different depending on the project. A hobby project doesn't need a hypervigilant git history, given you're usually just using git as a special save button. A rebasing fork will probably want to structure it's commits more on a per-patch basis (since they should be kept on top of all other commits), so most conventional advice doesn't make sense (since the git commit in this situation also acts as the code comment for the patches; you're usually trying to keep patches as small as possible for ease of maintenance). It's when you get professional that you'll want a commit style.
It’s not git’s fault if you choose not to use git(1). Trailers work great with it. You can use other tools that claim some level of compliance with git, but you do so with the understanding that YMMV.
Ultimately git is a tool for version control and software collaboration, so what you end up doing should encompass the tools that people use. It's easier to find a compromise than to hardline on a position that requires a lot more upfront work (it's much harder to switch people off of software that they are familiar with than you might expect.)
The answer to "my tool doesn't render trailers" is not "let's waste the short message" it's "then don't use that crap tool"
So, it is not for you anyway, as the problem it solves is already solved for you.