Nothing - in the context of angular project, which this is not. They are not general enough, everything isn't angular.
But if you want to compare, I also dislike how they choose to expand the line width to arbitrarily accommodate certain git web uis but shun minimum terminal widths.
Shouldn't your terminal view be able to wrap the text itself before showing it to you? That seems a UI display issue rather than one to solve by changing the underlying data representation. I understand why that's not good with code but commits are almost always non-code.
You know what, that's a fair point, but it's also just not how it works...
The reason for the 72 rule is that minimum terminal columns (since the beginning of time) is 80. git-log will pad the message with a 4 space margin, so to keep it centred you want it to be 72... alternatively to keep it from sprawling to illegible lengths you want to hard wrap it at about that width anyway.
So you will find one of 2 undesirable things happen if you don't hard wrap to this length:
1. Your terminal or pager _will_ wrap the text, but knows nothing of the formatting, so it will wrap onto the next lines without indentation (this does reduce legibility, making it harder to see where one commit ends and another begins in the full log).
2. Your terminal or pager _wont_ wrap, in which case have fun scrolling to the right - a lot.
You could rightly argue that if the terminal + cli + pager and git were one monolithic UI, then it would have a more holistic view of whats going on and smarter decisions could be made - but then we lose all the benefits of those separations (the unix way). There is no win win, but it is at least pretty trivial to hard wrap text automatically in your editor.
But if you want to compare, I also dislike how they choose to expand the line width to arbitrarily accommodate certain git web uis but shun minimum terminal widths.