I'd argue "why a method exists" should be addressed with naming and javadocs, not in the commit message. Why split the meaning of the code between the code itself and the commit messages?
And if it's not possible to document inline, the PR docs or code review comments should address this. Then future onlookers can use `blame` to see the context.
Commit messages should describe the change, not the code. This explains why the code was changed from whatever it was before, but not what the code does.
This can be important information e.g. when troubleshooting bugs, since it could explain the developer's thinking. Like in Chesterton's Fence; why on earth would you do something like this?
