When you merge the dev branch in the feature branch, you create a new commit with 2 ancestors. While this is all done very well in git and allows for perfect inspection, it makes it nonetheless harder to follow the history of your feature branch, since now you have two sources for changes. I just find it easier to make the history linear in that case, because it is easier to analyse in retrospect.
I actually prefer having two ancestors, because you can analyse different kinds of change in isolation. If your branch was to add a new widget to the UI, and there's a regression I'm trying to find in the backend data munging code, it's better if I can trivially ignore all the changes from the new-ui-widget branch, because I know that's very unlikely to have broken the data munging. That's harder to do if you've linearised the history.
Not really, because every changeset from the new-ui-widget branch shows up after the point at which the rebase happened, so there is a clear cutoff in the git log between branch changes and master/upstream changes after you've rebased.
