In accounting, there's a principle called convention in consistency, which is where you use the same accounting conventions over different time periods. This lets investors understand the business over time. It doesn't mean that you shouldn't make any changes, but changes and their impacts should be documented.
Good software development follows a similar principle of convention in consistency. There are many correct ways to develop software (Squash, Merge, or Rebase for one example). How should you name services or variables? How should you structure your git commit message?
There's no true right answer, but inconsistency in correct-but-different approaches slows developer velocity down. Programs become more difficult to debug over time when subtle patterns change (e.g., a hypothetical service that was deployed differently than all others).
There doesn't need to be convention in everything either. Enforcing convention in stylistic commit messages (such as prefixes like bugfix or rpc) might not be worth the trouble – that information can be reconstructed or found elsewhere. But for the most part, convention in consistency can go a long way.