The commit graph is a full-blown DAG that you can operate on and form in any way you like that helps you achieve your goals. When merging something in you get back pointers to (at least) two parents that let you see what came from which branch, and a merge commit has its own commit message that lets you describe overarching goals. Even when doing rebase-before-merge flow you can still group things by merge commits, which are often used to have PRs referenced in the repository while keeping the history effectively linear and easy to browse. This way you keep the one central unit of information management in Git representing what it's supposed to - the atomic unit of change that you can build upon and traverse in various ways depending on context, rather than force larger things to squeeze into it for no good reason.

(and if you hadn't squashed on merge, short-lived branches wouldn't even "disappear" in the first place as you would still see them decorated in "git log" on commits that were merged in)