I end up with a lot of "Interim commit on foobarbaz" because I'm leaving work and want to push my code just-in-case. Refolding those into "foobarbaz: feature 1" is a lot nicer.

The central repo is not meant as a place to backup your working tree. That's the point of git stash, and local branches. If you're worried about losing your working tree, back it up!

Then have them push the experimental branches and perform the rebase on a temporary branch, but it's still no excuse to have a clean feature history.

I think I wasn't clear. I like to be able to see completely experimental entirely thrown-away approaches in branches like you suggest, but I also like to see the little hints of partial experiments that a "dirty" history shows. My point is that on projects with focused teams where everybody is or should be an expert, literally the more history I can access, the better. Things like "did somebody already try and fail to refactor this class? What was there approach? Can I actually do better, or am I just headed down the same rabbit hole?" are invaluable to me, and the best way to answer those questions is to see "dirty" remnants of things people have tried and un-tried in the history. History can be forensics, and in forensics you don't want things to be "clean".

I used to do this, but I've started using

  git checkout master
  git diff master..featurebranch | git apply

instead.