Actually PL/SQL and perl can complement each other...

With a stored procedure, you can abstract your API more efficienty in some situations. For instance, you could create a stored procedure called 'add_customer' or 'ship_order', supply it with all the necessary arguments, and have the stored procedure take care of validating the arguments and inserting and updating all the proper tables (assuming that there's more than one table involved in such a transaction, of course you can develop a perl module to do your 'add_customer' subroutines, etc). And since stored procedures are executed on the database server, there is a lot less network traffic or traffic between the app and the database server. With a two-tiered approach, there's a potential to more easily develop the app on other platforms, where (gasp) perl might not be available, or you just need a different interface.

Downsides: stored procedures are usually not portable between database vendors; you're now developing one app in more than one language, so you need both skillsets available.