We do code reviews at work. And one of the thing that I care about when reviewing any Pull Request, is whether the commit message is easy to read and whether it represents the change that was introduced in a meaningful and clear way.
In fact, a good commit message goes a long way in ensuring that collaborators understand what is going on in the project at a higher level, before diving into the code itself. It can also help while debugging as it will help you decide which hashes to use with git-bisect. Finally, taking the time to write a good commit message allows the author to reflect on the change that s/he just introduced.
Unfortunately, while writing a good commit message may seem like a simple topic, it is surprising how very few developers actually care to do it right. There are two aspects to it: The form and the content. Both of these aspects have been written about by Chris Beams, who described 7 rules to writing a good commit message. If you use any form of source control at Work and care about the sanity of your team, then go read it, pretty please.