I've seen both and done both.
Mr. Ganssle has talked about this on occasion:
http://www.ganssle.com/All the benefits and hazards pointed out above apply. There are a few things that can help guide the choice:
1. Is there a process that is highly timing dependent, processes a lot of interrupts, run in "real-time", etc.? This may benefit from being it's own separate processor.
2. Is there a process that channels a lot of data, such as video or audio that is likely to cause system-wide issues if it's caught up in some waiting process? This may benefit from being it's own separate processor.
3. Are there boards connected by long cabling that have to do complex tasks but are relatively low bandwidth? A remote processor can turn a lot of parallel lines / inputs / outputs into a serial channel.
4. Are there boards connected to very different environments? For instance, one connects to a computer using USB while the other controls motors on 240 VAC. The necessity of optical isolation makes it attractive to use a separate processor.
Just like using multiple tasks on one processor, it's a matter of using the right set of tools for the job.
Figure that bootloading and updating complexity might go on the order of n
2. However, that is somewhat mitigated by moving tasks to remote processors. So instead of 20 tasks on the main one, perhaps it's down to 10 with other tasks distributed across the others.
Depending on the organization you may be able to more readily split it up between engineers.
Depending on the product line it may also make sense. For instance, perhaps the base model needs only a minimum amount of I/O, while a more expanded model really only needs the same overall processing power but has extra modules to support the new options. This allows a solution with a common main processor board with peripherals that get added.