The processor that handles the display must get instructions what to do. That can be low-level or high-level.

But these instructions depends on state information - key presses, menu selections, measurements collected by the slaves.

If the current master processor needs to make a lot of filtering and decisions of the key presses and measurements before being able to decide what should be drawn, then there can be a reason to separate that functionality from the functionality of actually performing the draw primitives on the display.

If the current master process does not need to do much job with incomming information before knowing what to do with the display, then the majority of the task performed in the current master processor will be to control the display. And in that case, the majority of the task will move to a new processor. And the current master will suddenly get very little to do.

In the end - it is meaningful to split the job into two, if both the control of the display, and the decision making based on incoming stimuli represents a significant amount of code and/or a significant amount of memory usage and/or a significant amount of CPU time.

If you have a situation where 10% is communication, 10% is decisions and 80% is display driving, then you don't get so much advantage by moving the 80% to a new processor. The new processor will need to do the 80% that is display driving, and it will need to do an unknown percent that represents the communication with the processor that handles the keyboard and slave processors.

Divide and conquer works best if both sides of the split has a significant size.

Scanning a keyboard normally represents very little code, state information or CPU time.
Handling a menu system normally represents very little code, state information or CPU time.
So the question then is if there will be a significant amount of work/code/state storage left for the original master to handle, if the display management is moved to a new processor.