The pattern we seem to be implementing consistently is any time you're going to have more than one BackgroundJob working on the same "object", you're better off storing that object in a table and passing the primary key into the BackgroundJob.
You have to keep in mind that BackgroundJobs may fail and be executed again. On the retry execution(s), It's better for the BackgroundJob to look up the data and get a "real-time" understanding of the state rather than relying on the potentially stale state passed in as an input.
We will also generally add auditing timestamps to our saved state as well, to understand how much work has been completed, which really aids in troubleshooting.
If you're doing some fire and forget, don't retry, processing, maybe this doesn't matter, but at least for us, that's like 2% of the type of code we write for Hangfire.