This is why the author information is retained and --signoff is used.
As Hongli Lai says in the comments: Most of the time, people who fork my projects make a bunch of changes, some which I want and some which I do not want. Cherry-picking instead of pulling totally makes sense in these situations.
This is the situation it was designed for - reviewing and signing off on individual commits, not merging branches.
I think the takeaway from this article is that we need to do a better job explaining the feature and what it's for. I understand now how someone new to the site would have no concept of email patch management or git cherry-pick and assume this is a nice interface for `git merge`.
As a first step, I've improved the text in the help dialogue to be more clear and link to the blog post + intro video more prominently. Maybe a next step would be making the actual help link itself (it's a small question mark next to Your <project> Fork Queue) more visible.
Also we could detect if it was your first time using the Fork Queue and offer help - that seems to be a popular idiom for web apps these days.
Perhaps in the future we can even offer a first class merge tool as the author suggests, but for now I've been extremely happy with how the Fork Queue compliments (but doesn't replace) my offline workflow.