You can commit as many times as you want in a feature branch and simply squash them down to one when you are finished.
My biggest concern here is, that you have to force push because of you rewrite the git history. That way you are most likely going to loose data.
If you need WIP commits to switch branches use the stash instead. You won't overload your history that way in a cleaner way.
Not entirely true. If you only squash when you merge the branch in, there's no need for the force-push.
Rebasing into the already pushed history should be flat out banned without question within teams, and force-push be disabled within configs. It's only in exceptional circumstances where you would actually need to do these.
But why do you need to squash while merging? The concept of merge tells that a branch is merged into the history by adding a merge commit. This commit reflects all differences. It's done automatically if possible - you need to resolve conflicts if it's not.
Correct me if I'm wrong but in my understanding a merge does nothing else than create a commit which is like a squashed representation.
Also, the git reflog keeps references to the pre-squash commits for a time, so the information is still there if you realise you squashed too much.
My recommendation is that commits should be atomic, minimal changes that take the source into a working state. This makes working with git bisect so much easier, but it does sometimes mean reordering and squashing commits.
A safety check in the case where you've got everything working but your history needs some tweaking is to note the hash of your tree in its working state, and verify that the tree you created after squashing has the same hash. You can do that by either inspecting the commit or diffing against the old reference.
If you are concerned about force push then make sure people understand the workflow and/or enforce branch creation policies on your central repo.
That way you don't push all your development commits to the remote and ensure a clean streamlined history.
A problem some teams I worked with have is that there is not one person working on a feature. Especially if you have feature-driven development teams at least 2-3 people actually work on it and a review process is included. That's why teams need to push their feature branches to the remote. Once they are merged: Feel free to delete them. But in my opinion it's hard to work on one feature with several people without distributing the feature branch.
We have a CI server testing every branch for every push - I'd regard it as rather bad to have failing builds 20 times a day.
Worst case could be that it goes live because of some processes related to continuous deployment (misconfiguration happens, in companies of every size) send this to live environments and there is a chance to ruin experience for your users.
In my experience it is extremely useful to have a bunch of "Unfinished; WIP" commits that I can look through to figure out what I was thinking yesterday when I started writing code. When I'm ready for other people to pull my commits, I'll rebase them into more meaningful commits (or often just one single commit).