They do...if you try to do all of your computation within the window procedures/callbacks of the gui...which is why you don't.

You run the gui in it's own thread and move any potentially time-expensive or complex processing into other threads.

That way the code in the gui thread need only maintain that state, and perform that processing required to maintain the gui. Everything else get spun off into other threads where the work can be coded as if it were a standalone program. All the state required by the algorithm is local, and the flow linear.

Only the initiation and return of results are transferred between the gui and the work threads and that is done by posting messages via a queue.

The gui remains resposive no matter how much work the work threads do. And, in a crisis, the user can instruct the gui to kill the background thread (or just suspend it), if it takes too long or he changes his mind about the results he needs.

To achieve the same thing using POE (or Tk->repeat or Tk->after) means breaking the long processing into small bits (and maintaining the state across callbacks!), to ensure that the rest of the application remains responsive. That is tedious and error prone and how much work can be done in each callback will vary depending upon the performance of the processor it runs on.

So you tune it for your 4GHz development box and when it arrives on your customers 1.5 GHz machine, the gui runs like molasses. Or you tune it for the 1.5 GHz machine and it takes 3 times as long on another customers 4.0 GHz machine as it should do, because it spend 50% of it's time saving and restoring state around iddy-biddy runs of the callback. You cannot tune for both scenarios. And programming state machines is hard.