This is an interesting idea that I've toyed with over the years. My fear is that it could be a bit of a footgun. In our project, some job processors retain a very large object array or promise (VLOAP) that wouldn't necessarily serialize well. I'd consider it an unwanted breaking change if all the sudden each run of a job saved a 500 record aggregate result array to my scheduled task collection.

A more subtle problem might be if a job returns a status object containing user's PII (name, email, address, etc). Tracking down PII leaks is hard enough without worrying about whether your async job runner is arbitrarily saving return values to the DB.

There's also circular references and promises, either of which could cause mongo to throw a fit.

If this were to be considered, I think it should be a more explicit process. Maybe calling job.setResult({ numSent: 7 }) and using that to assign an explicit prop on the job would be a better approach.

At the very least, the behavior should be opt in, at the runner level and/or at the job level.