Both approaches have value. And you'll find books advocating both ways.
Fossil takes a stance, git doesn't. It makes fossil less versatile but it is not a mistake. They never claimed Fossil to be the perfect solution for every project.
A nice feature would be the ability to group and split commits afterwards; like adding a "novel branch". So that you could keep both the exact history and a parallel high level description.
Your high-level description resemble a cover letter used on some open-source project to introduce a patch series, justifying the changes.
You could achieve the same by using an empty commit, or tracking those in the bug tracker.
DCVSs are already complex enough, this just seems like scope creep, trying to emulate a feature that is actually part of another tool (the bug tracker or the mailing list, depending on the structure).
Another issue is that it would foster a mentality where people would simply don't care about the exact history and push really badly structured commits, relying on the second-level history to explain their work. Except that if someone publishes something, it's not for this person, it's to be read by other people. The dev could keep a local branch with all their commits if they are so inclined, but that should never be sent to a shared server.
Most people are already bad enough at writing proper commits and dividing their work, I think your feature would make it worse.
Not after the fact. It's too late then, and it won't get done. History has to be pretty when you push it. The idea of being able to group commits is very nice, and IIUC BitKeeper had that.
I think I might’ve read something like that in the Pro Git book and it rings true with me.
The philosophy of Fossil is to preserve the full history, which I think is a mistake.