The current version looks better. I would add that the flag adjustment should also factor in honeypots seen. This version will punish flaggers (good or bad) with a large flagging history who've seen no honeypots.

-(1-(f/(t+1))

goes to zero as t goes to infinity--desirable when someone has seen and not flagged honeypots, but not as desirable when someone hasn't (which would be any user with many flags at the time of algorithm implementation).

I went back and read your footnotes. Footnote [1] is indeed a linkbait-y article. To me, it demonstrates a behavior described in another comment here: upvote as a save function. The title looks interesting, and in the middle of a work day, one may not have time for a long article. There's even more incentive to use it as a save as the front page volume cycles more.

Personally, I think that this 'noise' in upvote value can be mitigated by adding a separate save function and perhaps even eliminating an upvote history visible to the user (migrating current upvote history over to save history first so users can still access their clippings).