If your goal here is to have linear history, then just use a merge commit when merging the PR to main and always use `git log --first-parent`. That will only show commits directly on main, and gives you a clean, linear history.
If you want to dig down into the subcommits from a merge, then you still can. This is useful if you are going back and bisecting to find a bug, as those individual commits may hold value.
You can also cherry pick or rollback the single merge commit, as it holds everything under it as a single unit.
This avoids changing history, and importantly, allows stacked PRs to exist cleanly.
Git bisect is one of the important reasons IMO to always squash-merge pull requests: Because the unit of review is the pull request.
I think this is all Github's fault, in the end, but I think we need to get Github to change and until then will keep using squash-merges.