Paul - thank you for responding and considering this!
I'm finding in my environment, that we report lots of stuff when something fails, but when it works we just move on. I typically write the output of a command to a logfile, and if the operation fails, I echo the logfile to the console, otherwise, I just delete the logfile. It doesn't need to be a logfile, perhaps just storing the lines in an array, but you get the picture.
Specifically about this "p4 sync" or "p4 unshelve", etc... I look at "node" step in console (or most other Jenkins API steps), and I see one line when node starts, and one line when the closure ends. Same for "stage", and quite a few others. For normal ops, I think that would be sufficient.
Because there are many actual P4 commands being executed for each Jenkins API step, that is where the logging/fail/success comes in.
I hope I'm answering your question. I see this as default logging is absolute minimum, but if something goes wrong, it shows on the console. The user has to do nothing.
+vote
also, this adds volume to the console log even though "quiet" is true in p4sync. Request is to reduce/eliminate but allow setting to re-engage if diagnostics required.