it's not "inspecting grains of sand". If you have any number of developers worth talking about, merge-oriented workflows can create incredibly unwieldly git histories very quickly. I'm talking about, at a very high level, just understanding the history of the project. If you have five feature branches going on, and your developers are all committing on a regular basis, understanding the history and cadence of your project work based on the git history is incredibly difficult when the events of the separate feature branches are all intermingled.

Your comparison is not apt in many ways. For one thing, open-source governance is extremely different than managing private codebases maintained by a single company. Nobody in open-source governance is reading git histories to figure out whether employees are struggling, who is performing, who is not performing, who is overworking, where the project is, whether or not people are duplicating their efforts, how to report progress to clients, etc. And besides, the Linux kernel uses an email-based, merge-oriented workflow anyway. Kernel patches are submitted via email. That's not at all representative of any company that I have ever worked for or any company that I know of. The Linux kernel history also has a network graph that is literally unviewable on Github because it's so complex. Again, not representative of 95% of the work for 95% of users on 95% of projects.

It's easy enough to select commits from one user, or squash whole branches. Our devs are judged on completed features they deliver at acceptable quality, not their commit history.

I'm not saying you shouldn't care, just that I don't believe this strategy will become mainstream unless it gets much easier to understand and use.