In my thinking so far, there are a couple of reasons.

1- The final TaskStatus object (the one with isComplete = true) is frozen and persisted in the database permanently. I'd like that status to include everything the task did, so I am having the tasks treat status fields (like segments and nextTasks) as append-only if they are taking advantage of iterative updates.

2- Tasks send messages to the coordinator over ZK by updating a znode, but the coordinator won't necessarily see every znode update. To avoid losing messages, the tasks will want to keep adding stuff to the znode rather than updating it with deltas.

If we sent statuses over http, I think it would be natural for tasks to send deltas and for the coordinator to union them all into a single TaskStatus object. With statuses over zk, I think this way works best even if it is annoying that the coordinator needs to make sure that its responses to task messages are idempotent.