Interesting questions: to answer the question of whether perl is suitable for banking, insurance, etc. applications: YES! I, myself, am an architect of a big, complicated healthcare administration (insurance and much, much more) application that is built on perl. Apache::ASP/mod_perl to be specific (as well as lots of plain-old-perl scripts running from crons and command lines for administrative purposes), on an Oracle backend.

Anyway, to the more interesting question about application frameworks like J2EE and similar things for perl, and the general question of complexity of things like J2EE... Well, my basic standpoint on this sort of thing is: of course it's complex. It's a complicated problem (more complicated than it seems to novices or, often, to stereotypical "suits" or "PHB"s, which fortunately the management at my company are generally not). Many of these problems include (at some level) some of the most difficult (often technically impossible at some level) problems in practical information theory: atomic transactional processing, distributed transactions, guaranteed delivery, cryptography, object-relational mapping, and many others.

Some of these can be fairly cleanly abstracted. The cryptography can (ususally) be easily abstracted (often quite transparently) behind ssl/ssh/https. Atomic transactions can (if you know what you're doing) be abstracted into a relational database... but it can't always be transparently abstracted. That is, the programmer has to understand that there is an atomic transaction going on, and that it is being handled by the relational database.

Some of these problems cannot be easily abstracted. Object-relational mapping, for example, is generally very hard to abstract, and frameworks that claim to do so transparently for you generally suck. They either kill your performance completely, or require you to work harder than you would have to if you were doing the object relational mapping yourself (as apropriate).

Anyway, my point is this: hard programming is hard programming. There's often no getting around having to understand the difficult issues, even if you have tools that do a lot of the work for you. The real thing that J2EE did wrong was to try to sell the lie that it made difficult programming the province of low-grade coders, and that it somehow made applications written by shitty programmers automatically good and correct and robust. Ultimately, they took the approach of trying to dumb down difficult concepts, as opposed to trying to simplify complicated tasks, and that is why J2EE is on the decline.