I have emphasized the simplicity gained by the Mediator pattern. However, there is a second big advantage which is decoupling. The decoupling process allows senders and requesters to be changed independently from each other.
You can replace one object in the structure with a different object without affecting the classes. You can add multiple objects to the structure.
The Mediator pattern enables you to plug in and pull out components with ease.
Another advantage is that subclassing is reduced. Since the Mediator becomes responsible for changes needed in the system, you only need to derive from the Mediator to handle a new system.
You generally do not need to subclass to support new connections.
There is one significant disadvantage to this pattern. Since the Mediator itself often needs to be very intimate with all the different classes, it can become extremely complex. This can make it difficult to maintain.

In order to have good object oriented design we have to create classes interacting one with each other. If certain principles are not applied the final framework will end in chaos where each object relies on many other objects in order to run. In order to avoid tightly coupled frameworks, we need a mechanism to facilitate the interaction between objects in such a way that objects are not aware of the existence of other objects.
Let's take the example of a screen. When we create the screen we add controls to the screen. This control needs to interact with all the other control. For example when a button is pressed, it must know if the data is valid in other controls. As you have seen if you created different applications using forms you don't have to modify each control class each time you add a new control to the form. All the operations between controls are managed by the form class itself. This class is called mediator.