I can’t speak generally, but I can describe how we’re using here both those methods.
We’re using local pub for syncronization on flow execution on IS (take a look at this recent thread: http://www.wmusers.com/forum/showthread.php?t=12553). Local published docs are sent to persistent queue of triggers (since documents are configured as guaranteed), so using disk space on DocumentStore directory.
We’re using broker publishing to delegate work to other ISes. This is the only way yo “engage” another IS to execute a task; this allow us to balance the load on more ISes. Docs are queue in the broker and read by trigger (as per trg config) and stored in the volatile queue (no need for persistent one, since they are safely stored on broker, and only dequeue if succesfully elaborated). Here space usage is mainly on broker side, since there are all sent docs.
Regarding CPU usage schema, maybe local pub will generates a pick (since all the operations are inside the IS) while broker pub will allow IS cpu usage balance, since part of the work is done on broker (but if broker & IS are on the same machine, general server load could be higher…).
Memory is not a problem, but you need to configure well triggers: docs are stored on queue (on disk) and read in memory to be sent to trigger service to be elaborated. So, if you have really big docs, maybe it’s fair to have no more than 2/3 parallel elaboration threads (some load tests are needed on this point).
If you need failover or load balance, I think the only way to go is broker pub, since this allows you to decouple IS that sends doc and IS that elaborates doc (they can be different).
Hope to hear someone else with more experience than me on this field