Thinking that providing additional context for commits is a waste of time is short-sighted. Yes, it requires more time and effort in the short-term (i.e. for creating the commit), but if it's a complex, long-lived project, then that extra effort will save a lot of time in the long run.

Sometimes the extra time and effort is already made up for in the review process, which without proper context could drag out and cause a lot of back and forth. Sometimes it might save somebody hours and days of investigation time. This is not to mention the benefits that both the author and the readers of the commit get by better understanding both the problem and the solution.

People are bad at finding out what is important and what is not. Most of the time I have to cut through not relevant stuff that others thought would be important for fixing some issue. Lot more than some insightful commit saved my day, but maybe that is just my environment.

Anyway good luck fixing anything trusting commit messages from long time ago. Code is truth and if you won't investigate you still don't know how it works.

Writing more code that no one understands the reason for is not better than writing explanations of why you wrote some code.

Then why not focus on writing readable code? And when you do need to write a workaround or something hard to understand, then document it in the code itself with a comment. It'll be recorded in the diff of the commit, plus it'll be more accessible when reading the codebase as a whole.

These aren't mutually exclusive things. Write readable code so people can see how you did it. Write complete commit messages so that people understand why you did it. Especially with older codebase, hairier things you inherit that are full of monsters and WTFs, you need both.

It's more work for you, but it saves the rest of the team even more time. It helps the dev reading it in three years understand, when he git blames to figure out why you did this strange thing.