TL; DR

It is the only thread that can directly manipulate the graphical interface to avoid competition problems. It stays in a loop waiting for events coming from the screen (clicks, keys, etc.) or directly from the program and applies all the changes sequentially.

Motivation

I confess that even reading an article quoted in the answer to the question that @Marconi left in the comment I did not know why EDT is the way it is.

If you really want to understand this, make an effort and read:

  

Multithreaded toolkits: A failed dream?

In short: developing a multithreading GUI framework, where multiple threads can manipulate the screen components, does not work in practice.

The author argues that at first creating a multithreading graphical interface seems almost trivial, just a matter of putting the locks in the right place.

However, screens have a nature that makes it not so simple: it accepts opposing concurrent events.

All this causes locks to not work well, often generating deadlocks and glitches.

The author says that a lot of effort was put in the time when the AWT was multithreading and they arrived in a kind of dead end. The solution was to do what virtually all other GUI frameworks did: switch to an EDT model.

He still argues that there are multithreading GUI implementations, but they only work well if the people who develop the GUI are the same ones who develop the framework, as this requires specific and detailed knowledge of the model. However, in a general-purpose framework made for large-scale use, this would never work well.

One of the ways to do this is by using invokeLater , but inside event handlers ( listeners ) this is not necessary because they run inside the AWT thread, which also implies that any processing within the EDT blocks the entire program.