Why EventDispatchThread in first place?

This is the design decision I don't understand.

Both Android and JME follow the policy that the thread that started an app is the UI thread and you take care to offload resource-consuming stuff to another threads.

In Swing, on the other hand, you use EventQueue.invokeLater(Runnable) for UI and SwingWorker for background processing.

Now, what's the main thread for?

As mentioned in this Sun article about thread, you can do whatever you want in the main thread, including building a GUI, even though it is risky.

• Swing methods are not thread-safe, but as long as no components (Swing or otherwise) have been realized (meaning that the component's paint() method has been or might be called), it was OK until 2004.
• Since 2004, as reminded in this SO question, it is mandatory to create the GUI in the EDT.

Back to the question:

Swing has not been implemented with the main thread solely related to GUI because that would force a pure multi-thread approach and:

• Component developers do not have to have an in-depth understanding of threads programming: Toolkits in which all components must fully support multithreaded access, can be difficult to extend, particularly for developers who are not expert at threads programming.

• Events are dispatched in a predictable order: The runnable objects enqueued by invokeLater() are dispatched from the same event queue as mouse and keyboard events, timer events, and paint requests.
  In toolkits where components support multithreaded access, component changes are interleaved with event processing at the whim of the thread scheduler. This makes comprehensive testing difficult or impossible.

• Less overhead: Toolkits that attempt to carefully lock critical sections can spend a substantial amount of time and space managing locks.
  Whenever the toolkit calls a method that might be implemented in client code (for example, any public or protected method in a public class), the toolkit must save its state and release all locks so that the client code can grab locks if necessary.
  When control returns from the method, the toolkit must regrab its locks and restore its state. All applications bear the cost of this, even though most applications do not require concurrent access to the GUI.

So the main thread can be used for initialization (of data and GUI, provided they do not take too much time), while most post-initialization GUI steps naturally occurs in the event-dispatching thread.
Once the GUI is visible, most programs are driven by events such as button actions or mouse clicks, which are always handled in the event-dispatching thread..