As someone who has a favorable inclination toward both perl, and GUIs (something that may be a tad uncommon) ... I think there is a single factor that is the blame for most of the harm and limitations inherent in GUI development. There is a prevalent view that a "GUI" is a *substitute* for a command line, or an alternative for those who are not willing to use one. This is a mistake.

Until this prevalent view becomes less prevalent, the drawbacks and justifiable misgivings about GUI development will probably not be displaced. This difficulty is compounded by the fact that the term GUI carries a whole host of differing connotations depending on who is using it, and in what context.

This is why I like to summarize this whole dilemma with what I call the "Photoshop Test." (with apologies to Turing)

GUIs will never be sufficiently flexible and powerful until you can run a graphically-intensive program (like Photoshop for example) in such a way that it is impossible to distinguish whether an instance of usage and output was generated by a human end-user or by an automated agent.

(Photoshop being a GUI-intensive application that everyone has at least heard of, no endorsement or evangelism of that particular product intended).

I use the Photoshop test because this naturally precludes and surpasses the definition of the term "GUI" that you typically see in the context of the Web (aka 'request-response' driven apps that consist of input forms, buttons, and other basic widgets primarily used to manipulate text, but little more than that).