The issue that concerns me is that those Gui-less jobs are almost always back-end jobs that are cost-centers. Although back-end systems are almost always mission critical, in nearly any corporation there is very significant pressure to keep cost-center budgets down. This has one of two effects on programmers:

First, if it is easy to find workers (because there are lots of Perl experts out there), it pushes salaries down. Managers bargain harder for a lower salary. If they don't get that lower salary from one candidate they like, they will be more willing to trade time for money and search for one they like as much but who is less pushy about pay. Since workers are plentiful it won't be that much extra time. Alternatively, if there is a second cheaper candidate who can do the job adequately but not as well, they will trade expectations for money and accept the less qualified but cheaper candidate.

Second, if it is not easy to find competent workers, salaries will remain high. In fact, they may even be higher than average, a situation developing with COBOL. According to payscale.com, the average COBOL salary in NYC is US $87,623. The average Perl salary is US $79,480. Ruby, Php, and Python for all their sex-appeal are also lower than COBOL.

However, the pressure to keep costs down will still remain. If salaries can't go lower, then the only other option is to reduce the dependence on such a high cost language. New projects will only use Perl if there is no other viable choice. There aren't a lot of projects where Perl would be the only possible choice. Better and more elegant doesn't cut it when team and long term maintenance costs are 10-30% higher than for that other less perfect language. Further, since the high salaries are due to the difficulty of finding good people, managers might well turn away from Perl simply because it is much less hassle to find good people in that other less perfect language.

If salaries and search costs for good people are high, there will also be significant pressure to replace legacy Perl systems so the installed base of Perl (and the jobs they supply) will also eventually dwindle. Just as businesses today are eager to get rid of COBOL systems whenever practical, they will start looking to replace their Perl systems as well. When business needs change they will lean towards rewrites/enhancements in a new cheaper language rather than make choices that further lock them into Perl for the long term. That warehouse distribution system (and Perl) is there, but for how long?

Don't get me wrong. There is a lot of money to be made at the bottom of the food chain supporting legacy systems. Some companies have been very successful at it. However, it is a niche market and the successful people know they are taking advantage of the dying and will have to move onto the next generation of legacy languages when the COBOL market shrinks too much.

It is taking COBOL a long time to die out, maybe even a (human) generation or two. For our lifetime and our careers there will be plenty of Perl jobs, but for Perl as a language, being relegated to the backend either means lower salaries or lower lifespan. Take your pick.

Perl's amazing at eliminating busywork. We find things we commonly do, over and over again, and we reduce it down to three letter function names, or a punctuation mark EXCEPT FOR GRAPHICS and graphical interfaces. Perhaps this is because noone can settle down and decide upon one thing, or because its too hardware dependent, or because it's too tied to a single OS, or maybe it is a complex task that has never been done simply ever--no matter the technology or language-- but at some point, some languages bridged (or are attempting to) this gap--regardless. Perl hasn't. Other languages, like Java or C# have visual tools that enable them to create components, hide the details, and generate sources that Perl doesn't. Perhaps the developers don't even know what their code is doing, because it's all generated, but do you think that matters to them? Probably not much.

For a language that more or less DEFINED automation, I find it regretable that there's no serious visual tools that automate things like gui creation in Perl... but I'm probably just being selfish--cuz I know I'd use such a tool.

Perhaps the problem is that Gui's are too machine dependent--too specific, and Perl's need to do everything 40 different ways (most of which are bad form, or no longer acceptable, btw) fails the closer it gets to hardware. Perhaps we're all such huge fans of GetOpt::Long that we're afraid of hurting commandline interface's feelings... ;)

One thing I do wonder. Suppose that the Perl 6 people decided to create a standard visual control inherent linguistically into Perl6... How long would it take Perl 5 to find a way to make it happen?

Perhaps the reason there's no visual tool for Perl is that Perl's just so darn easy at getting the job done quick and dirty that no one's ever seen the need to make the job any easier.

But I think ultimately we're missing out. We need some fluffy stuff too--some panache' or something to attract the trivial programmers too... because like it or not, they give a language momentum. Sometimes I think Perl's like the smart kid with the personal hygeine problems in the back of the computer lab, who thinks that because we can prove the teacher's no computer expert, we'll get the babes. Ultimately to be relevant mainstream, and thus able to propagate our genetically superior brains through the next generation, we need the whole package, including a few seemingly nonsensical social skills. (Okay that's a stupid painful analogy... I'm going to stop now... before I realize what a loser I am... and go code something in a truly tawdry/socially promiscuous language like C#...)

Tk, Tkx, Prima, Gtk2, SDL, Wx, Qt, OpenGL, Win32::GUI, Inline::Inline::Java XUL::Gui, Win32::GUI::XMLBuilder, Gtk2::GladeXML, wxGlade, (GUI) Windows Programming FAQ

For a language that more or less DEFINED automation, I find it regretable that there's no serious visual tools that automate things like gui creation in Perl

I used The GUI Loft and ZooZ 5 years ago. It's sad they're not updated, they were pretty good tools.
OTOH, you can do a lot of good job with just typing the Tk code. You don't need the GUI designer in the most cases, because the tool allows you to be faster with the keyboard than the mouse. For a serious perl-lazy developer like me that means a lot. I can type faster this Tcl code "pack [button .b -text Exit -command Exit] -padx 10 -pady 20" than setting it all by mouse.

One thing I do wonder. Suppose that the Perl 6 people decided to create a standard visual control inherent linguistically into Perl6... How long would it take Perl 5 to find a way to make it happen?

Could you please define "inherent linguistically"? I don't know any language that make any accommodations for visual controls. At best, some bundle a library.

"And... in (for example) the case of “the Web,” where, exactly, does the software begin and then cease to be “graphic?” Is Perlmonks “graphic?” Amazon.com? eBay? Perl programs all! Are they “graphic,” or not?"

No, they aren't. At least they are not good examples of visual design whether or not you separate form from function. In fact Amazon.com is a perfect example. I've been a member for years and still have a hard time finding account information. As for the form of the site, it hasn't exactly been placed in the same category as Apple or BMW for style.

So if that's what we're going to consider "graphic" simply because they chose a font and one or two colors the relevancy issue becomes more pronounced. Other languages have a culture that, at least somewhat, embrace visual design. There is no reason why Perl couldn't do the same and prosper from it as it has in from it's other accomplishments