I have a bit of experience using YUI, ExtJS, etc, for creating web applications. Note that these are front-end technologies, not back-end. Javascript is the language that executes in the browser, for better or worse.
If you are doing a simple "form based" web site, then the front-end toolkits don't matter too much. This is because these form based, low-interactivity applications can all be done using some backend language, usually PHP, although Perl+Mason, I think is a compelling alternative (Amazon uses this I think).
The toolkits like YUI come in handy when you want to either: 1) do AJAX-like things (interactive client/server, incremental responses, high interactivity), or 2) do GUI-like things in the browser (e.g. ExtJS widget set). The commonality in these two aspects is they require lots of code in the browser to do interesting things.
The first thing to look for in a Javascript toolkit is the lowest level tasks: normalizing the browser environment, DOM manipulation and basic animation. Part of normalizing the browser is the "event model", which generally includes ability to make calls to the server (the async ajax call, XMLHTTP). Normalizing the browser environment means that you can (theoretically) use the toolkit API and things will work the same on any browser. Note that the toolkits help but don't fix everything, they just make it _possible_ to not have to write a slightly different version for every browser. YUI, ExtJS and the other toolkits all have some aspect of this (look for the "event model" part of the toolkit). JQuery concentrates on DOM manipulation and is has more power in this area. YUI has won many awards and was originally one of the "trailblazers", ExtJS was originally based on YUI, but then yanked out the YUI code and did their own. There are many other JS toolkits out there as well (Dojo, etc.)
One of my pet peeves is I really dislike toolkits that give people "the ability to program in language X because they don't like Javascript". These "program in X and translate to Y" approaches never work well. They do make things easier for people to write simple programs. Unfortunately, the whole reason for a Javascript front-end toolkit, is to do interesting things on the front-end that you can't do any other way. So I'd veer away from things like the Google toolkit (program in Java so you don't have to learn JavaScript), or Mochi (program in Python so you don't have to learn JavaScript). Just my opinion, my preference (other people probably love these approaches). I think these are knee jerk reactions to Javascript's initial problems, but these are largely solved, and now people are concentrating on making Javascript execute efficiently. So learning Javascript/DOM/Browser will in the end let you do interesting things.
One interesting thing you will see if you take these toolkits apart is that they all do their magic by DOM manipulation and CSS. The browser gives a lot of display power by it's underlying technologies. You could contrast this to the types of code you might find in a desktop windowing application (if you've written for the GUI and looked under the hood). By using these browser technologies, the toolkits allow you to modify things at all levels (e.g. skinning is fairly trivial). This is one reason why I think people love JQuery => it assumes that you are going to do lots of manipulation via CSS/DOM and can achieve all sorts of custom effects. Contrast this to heavier weight things like YUI and ExtJS, which assume that programmers want "Browser widgets, similar to GUI widgets". ExtJS goes the furthest in this respect (see demos on website). Note that a lot of this power is wasted unless you use AJAX, or go one step further (attempt to build a standalone app in the browser). Most web applications show a form, let you enter things in the form, hit OK and then everything from that point on is handled on the back end.
So what does it mean "have a highly customizable UI"? If it means you have lots of forms, then the CRUD approach is probably a good one. This is like Ruby on Rails or any of these systems that impose a simple CRUD framework on you. The benefit of these is you can make a lot of fast early progress, as long as your application fits the CRUD model. If it veers outside the framework model, then you have to learn the framework (and you may learn that you now need an expert in the framework to make the types of modifications you need). Personally, I prefer libraries to frameworks, but that's because I like to "know everything". If "highly customizable UI" means "I need something that acts like a desktop app", then you need to pay more attention to the Javascript part as the CRUD part won't really help you.
I'd strongly recommend implementing a simple end-to-end piece of your application, something very simple. You need broad, shallow knowledge first, rather than deep knowledge of any particular piece. Once you see the uses and ways things fit together, you'll be in a lot better shape to understand which framework to pick. Just Keep It Simple, and code like the wind (prototyping). Then throw that away - it's just for learning. The first way I'd do it is using bare bones technologies to see how everything fits. Don't waste time making it perfect, just see how everything fits together. In fact, if you can find a sample on the web somewhere, just go through the motions of typing that in, e.g.: Perl DBI to access MySQL database, with PHP (or Perl+Mason) in apache, with a tiny bit of YUI. It's important to see how the pieces fit, and you'll have to do this eventually anyway (learn how things fit). Once you've done that you can select a framework successfully. I'd hold off on a decision until you did some really simple prototyping.
BTW, I've used the following stacks for web design of reasonably complex projects: YUI|ExtJS|JQuery, apache, php|perl|c/c++, Perl::DBI|php_oc9, MySQL|Oracle.
Note, since you are posting to perlmonks, I assume you are going to use Perl::DBI for the backend access (not sure, but I'd guess this is what Catalyst uses). So understanding that will be a useful starting point.