I put a lot of effort into commit messages and try to always give a good summary of what (and more importantly why) the change was made. I consider it almost as important as the code itself, because it serves as a form of documentation, as well as a way of communicating to both other team members and my future self.
I struggle immensely with writing normal documentation, whether it be fine-grained stuff like descriptions of functions/classes, or higher-level architectural issues (I have written a PhD thesis so I can do it, it's just a tremendously difficult undertaking). I treat commit messages like a second best alternative to code documentation, and they're a lot easier to write because all the information is fresh in my head at the time I make a commit. A good log can also serve as a solid starting point for later writing other forms of documentation.
Git is designed as a decentralised version control system; pull requests are something that the major repository hosting providers have added, and while I appreciate the existence of those features I'd rather not rely on them at least in terms of the long-term record for a project. In the case of pull requests, someone who is already writing detailed commit messages basically has double the work if they want to communicate the same kind of information in pull request descriptions/comments, though you can just make the comments a copy of the log (BitBucket does this). And if you want to migrate from one provider to another you can lose all this extra context that is not in the repository itself.
Other than attempt to increase lock-in, I don't understand why they would make this change, and it seems like it's based on assumptions about how some teams use git without taking into account other styles - there's considerable variety in practices between teams and for those that rely on the commit messages more heavily this seems like it's going to make for a worse experience.