There is a distinction between programming languages and GUI libraries/Widget factories.
Perl is just a programming language, It has no GUI bindings of it's own, there are perl bindings for the popular GUI factories like TK/GTK/Wx/Qt, etc but they are not part of perl - just as Java is a language but requires something like Swing/AWT for GUI widgets or like C/C++ is just a language but requires libraries for TK/GTK/Wx/Qt, etc. It is just that Micro$oft tends to release the native GUI bindings as part of the core language because that is what "windows" programming is all about - GUI programming. As of late, with the advent of portable applications, we have begun to see GTK/Qt/Wx bindings written for the traditional win32 languages such as VC++, C#, .NET, VB, etc but their outreach is still in it's infancy.
Writing a GUI perl app is still a bit of a hassle as the GUI bindings for perl you prefer might not be available on the OS. For e.g. on most desktop *nixes, Qt/Gtk libraries are usually present by default but the perl bindings for Qt/Gtk aren't, it's even rarer to see GUI bindings for perl on something like Win32 (I don't know much about Macs, but I guess it's the same case there). You could ship the perl bindings for the GUI factory of your choice but then you need to take the different OSes/Platforms (win32 vs *nix) and architectures (32 vs 64 bit win32 for e.g.) into account and distribute the right bindings accordingly. You could simply present prerequisites for the end-user to be able to choose the right bindings, but then not all end-users are that clever.
Writing portable applications will always present problems, whether the language be perl or C or C++. Java does well here, but it kinda made a trade-off, choosing portability over speed.
perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er