And squash merge is still an ee-only (paid-only) feature ¯\_(ツ)_/¯
I do not understand the appeal of squashed merges. The only pro i know of is the ease of reverting a merge. On the cons side: you obfuscate an entire branch into a single commit, effectively making git-bisect useless. Furthermore, if multiple people collaborate on a branch, all code blames to one person, quite literally rewriting the code history.
It's going to be highly pipeline, workflow, and team interaction dependent. In my place of work you generally only have one person working on a branch to add small, modular features. For releases we cut master into release branches. We fairly frequently need to downstream a commit from master into the staging branch and more rarely the production branch. The squash allows for a quick and easy cherry-pick of the feature to apply downstream.
If the code change is not widespread, I would always encourage a squash. Commits to two different parts of the codebase that do not directly rely on each other on the other hand should remain separate.