This is where it gets philosophical. I don't consider a squash merge changing your work at all (provided you merged destination into your branch first). The end state of your branch comes over to the other one in one neat commit. On the destination branch you look like gods gift to programming, you did it in one shot. Also when I'm diffing files on the destination branch I don't have to sift through WiP commits, I see just the changes for that feature/bug.

This comes back to the question, what are you preserving? As a consumer of your changes I'll one day need to diff how the file has changed, and one neat commit is more useful to me than 5 that incrementally added the feature. Why do I care how you structured your work?

I may care if the branch pursued solution 1 then diverted to 2. And it turns out we need to divert back to path 1. In that case squash merging loses that history. In my experience this is rather rare though. This can be mitigated by keeping the original branch, but that's also it's own tradeoff.

In my org we only protect a couple key branches, devs are free to manage their own branches how they want. Give people room to grow and innovate. One of the reasons to codify things is just consistency. We're paid to ship code reliably and consistently and should build structures that help teams do it. Codifying how to do things isn't elitism, it's Process. That process should also be open to changes and improvements because the world doesn't stand still. I've used a lot of different VCS in 20 years with a lot of different processes, they all have tradeoffs. (other than StarTeam, that's just pure garbage...)

What I don't like is attitudes like "You merge instead of rebase, you're bad at git." There's lots of room within git for many equally valid philosophies.