I worked in teams that did squash merge and in teams that didn't. And in teams where some did and some didn't, on the same repo. In the grand scheme of things it didn't matter, except for hardliners who had nothing better to talk about.
Anyway, the _real_ question is what color to paint the bike shed?
However, it's an imperfect world and there are trade-offs. It's hard to train people to do things the right way, and then policing when they do it the wrong way or putting roadblocks in place to make them do it the right way takes energy, and often the benefit is minor. It really depends on how frequently you pore through your history to find an offending bug and a whole bunch of other team policy that isn't directly related to git commits.
I used to spend a lot of energy rebasing so that I could have a beautiful history, but honestly it hasn't benefited me that much. I still rebase, but I'm not so strict about it on my commits, nor others. I'd rather spend my focus and energy elsewhere.
Just do what the team is comfortable with and be flexible.
If the team doesn't see an issue with it, then using those flags should be mandated since what the team is really interested is just snapshots of the codebase. Any associated message (the commit message) is effectively useless and ignored, so why bother even including it?