This is sort of half design issue and half as designed.
The design issue relates to the rough inability to actually display any of the user/upgrade details (without big hacks). The log table was originally generally designed for internal use, so the primary relationship is to one of the user upgrade state tables. If no action is being taken, we won't have a record to insert into these tables, so we can'd easily display the upgrade or user involved (it could potentially be done with some string parsing on the "custom" field). In hindsight, as a general logging/debugging tool, this isn't ideal.
The as designed part relates to this being a general logging/debugging tool that logs everything (from PayPal). While it stands to reason that if they receive subscr_signup, they should receive subscr_payment, we have seen plenty of weird things from PayPal's callbacks. By silencing one of these messages, it may interfere with some amount of debugging, so I'd rather not do that. You should be able to do this yourself if you wanted to in the next release by extending the class and returning a false log type.
What I'm looking at doing is tweaking the message for a few of these situations to at least have a more descriptive message.
Worth noting that this is sort of a moot point -- or at least a different point -- in the long term, in light of XF2's more generic payment system/approach.
