Rebases are frequently much harder than merges if there's any conflicts. Rebases means replaying your commits on a different base. If you have multiple commits to an area of the code which is different in the new base, you'll be resolving conflicts repeatedly. Depending on how much work and how many commits in your dev branch, it can easily get to be more effort than it's worth.
IMO a clean commit tree that looks pretty and doesn't have repeated merges of the updated base branch is severely overrated, particularly in a team environment. If you've ever pushed your dev branch and you rebase, you've probably made someone else's day miserable, maybe not today, but some day very soon.
If you have someone dedicated to nice git history, and lock down your git server with sufficient hooks to ensure whichever branch you want to have a beautiful history has one, perhaps it can be made to work. I don't really see the upside.
Source control is occasionally - not often, but occasionally - useful for going back in time. Mostly it's useful for avoiding conflict in the face of concurrent commits, and for finding out why a particular line of code was written (we put JIRA task ids in every commit message). But even with the time travelling, all you need is something you can traverse. How pretty it looks isn't very functional.