Semantic diffs are great (I did some experiments with it myself [0]), but we can't entirely automate away "narrative problems" in a PR. No matter how good a diff is, a diff tells you
what changed but not
why and sometimes not even
how. That's what we need good commit messages for. That's what we need good PR descriptions to do. If a branch has a ton of seemingly unrelated files modified (automated tool output or not), sometimes you have to ask the narrative questions: "Why did this change? What does it have to do with the other changes in this branch?"
Admittedly, narrative problems are hard to solve in general. It's a lot easier to "build a new tool" than to train a junior developer to always explain why/how in commit messages, to order their commits to "tell a story" of what the branch accomplishes, to avoid unrelated changes in digressions and asides along the way (moving those into their own branches/narratives), to tell that story in a PR description in a way that is useful to understanding the whys/hows of the branch (especially if the commits themselves lack some of the narrative or aren't ordered well for proper storytelling). I often settle for one or two of those at a time from a given junior developer.
I don't think we can automate ourselves out of narrative problems. I think narrative problems are one of the unsung creative problems of our industry and something that separates good programmers from great programmers. It's a human skill that takes practice.
> I feel like git was perfect when "code" was nearly almost completely text and patches were sent over email
That "perfect" never existed. Even codebases like the Linux kernel that work entirely in email still have their random binary blobs (often from outside vendors) and auto-generated files from tools. What the email flow focuses, arguably to some (such as many of the folks at Sourcehut) better than most other PR tools, is that conversation around the narrative and they why/hows. You expect a lengthy narrative discussion in a mailing list. Sometimes people see those comment fields in a Github PR and expect then to be less about narrative and more about nitpicking specific lines than having narrative discussions. (Nitpicking happens in mailing list discussions, too. It's mostly unavoidable. But to nitpick on a mailing list you have to do a lot more copying and pasting by hand.) There is something of a different story telling "pressure" when you are staring at an empty email with a file auto-attached than when you click the PR button in Github and get pages full of diffs and all the commit logs laid out before you before you ever start writing. (Sometimes people do see that and think their job is "done" and what they would write in the PR description would be redundant, because it is not a "blank email" that needs a greetings and salutation and maybe a description of the attachment.)
[0] https://github.com/WorldMaker/tokdiff