I can sympathize with this take. Although I'm generally fine with either async or sync--whichever is most efficient--it seems that individuals don't usually know which is right for them.
I'll take this further: I think that bad commit messages breed resentment. It's highly context dependent, but needing to understand some code and its historical context is already a big challenge. git-blaming your way back through time only to encounter brain dump commit messages full of ambiguity and non-essential information is excruciating. Writing good commit messages--like any technical writing--is more art than procedure, and it's hard to do well without feedback and revision. I believe that commit messages should be subject to the same level of review as the code they are presumably documenting.
This is such an important feature that has a direct impact on code quality and time savings that I'm not sure why it isn't a priority feature. As a reviewer, having to choose between "review everything again" or "trust the submitter didn't introduce extra changes in the revised pr" is such a terrible choice to have to make.
Migrating away from a development model based on attaching patches to bugzilla tickets is sure to improve the development experience, especially for new contributes. Good move switching.
This sounds really similar to some of the work coming out of Vectorized on Redpanda [0]. They're building a Kafka API compatible system in C++ that's apparently achieving significant performance gains (throughput, tail latency) while maintaining operational simplicity.
[0]: https://makedist.com/projects/cruzdb/