Public history and private history. Or maybe changes to production vs changes as you developed.

I care more about the merge then the commits. (In github parlance, the Pull Request) This workflow turns commits throughout time into a single change against the master (while still preserving the commit history). Conceptually this is a lot easier for me to see what's changing, and to deal with issues. So I guess I disagree with point #1)

In a continues delivery environment this workflow makes sense because the log accurately shows the history of the changes to the app in production instead of the development environments. (Merge, Merge, Merge)

#2 doesn't make sense to me, if you rebase you're up to date with master as of the branching commit.

Whatever works best for your team!