That information can and should be a part of the commit body. An extra commit just for that information is, in my opinion, a hack and a workaround.
I guess we have fundamental differences on how a tree should be structured. It's more of a DAG in your case, but I prefer to keep a tree a tree.
Not sure I follow your argument. How would you put information about the semantic meaning of a series of commits into "the commit body"?
The only point I'm making essentially is that "the commit" is too granular to capture all the information you need about your work and its history. You need some kind of grouping mechanism as well. It doesn't have to be merge commits, necessarily. But as I understood it, your original argument was that "there is no need for anything higher level than a commit." But there clearly is imo.
If you tag HEAD after each merged PR you can still see which commits belong together, they'll be between two tags.
You want both that goal and the individual tasks which achieved it to be visible.