Logs are a product, and your user is you at three in the morning
Most logging is written for the moment the code is written. It should be written for the moment the code fails, by a person who has forgotten everything, under time pressure, reading through a search box.
That single change of audience settles most of the arguments.
What follows from it
Log the inputs, not the intention. "Processing batch" tells the three-in-the-morning reader nothing. "processing batch id=b-4471 urls=39 source=sitemap" tells them what to search for next.
One line per event, and make it greppable. A log entry split across four lines cannot be filtered. Key-value pairs beat prose because prose cannot be queried.
Log the decision, not just the outcome. "skipped" is a dead end. "skipped reason= already-archived id=b-4471" ends the investigation instead of starting one.
Never log a failure without the thing that failed. An exception with no identifier is a sentence with no subject. Half the stack traces I have been sent over the years could not be acted on because the one field needed to find the record was not in the line.
The rule I actually apply
Before adding a log line, ask: if this is the only line I have, can I take an action? If the answer is no, either add the fields that make it actionable, or do not add the line. Volume is not the enemy; unactionable volume is.
And a small one that pays constantly
Log the version. Build number, commit hash, whatever you have, once at startup. The number of incidents that turn out to be "the old build was still running somewhere" is much larger than anyone expects, and that one line answers it before the investigation begins.