Header access is really a moot point -- all you have to do in perl is print out your headers to STDOUT; I probably should not have brought that one up. But when it comes to your POST, GET, and COOKIE hashes, again, in PHP you don't need to load another library to get access to those; you simply have them available.
Regarding database access in PHP, I actually don't use the database functions directly. I install PEAR::DB (which you allude to), which is similar to DBI, as what it does is abstract the calls for the various DB functions, and provides things like prepared statements, convenience wrappers for simple things like retrieving a single value or row, etc. I am aware that it is slower than ADODB, but honestly, on the hardware I use, this isn't that big of an issue. If I want an upgrade in speed, I'll probably switch to PEAR::MDB2 and/or PHP's PDO layer (once stable). Finally, since I control my own servers, I only compile in database support for those RDBMS' that I use.
(Which brings me to another point: I've seen a number of sites slam PHP for the number of functions it has. However, not all functions are available by default; if you compile PHP to only use the extensions you need, you can cut the number of functions down tremendously. Granted, I've never understood the naming conventions, nor why there are so many string functions that all do similar, but not exactly the same, things.)
You mention CGI::Application::Plugin::ValidateRM... funny you should mention that, as I finally ported the plugin functionality over to Cgiapp.clas.php in the 1.7.0 release, which happened this past Friday evening (20 May 2005). Bundled with the class is Cgiapp_Plugin_HTML_QuickForm. HTML_QuickForm is a PEAR library for form creation/validation, and is similar in functionality to Data::FormValidator. It still needs a little testing and work -- integration with template systems other than Smarty is currently untested -- but it does work, and it makes form validation in Cgiapp a snap.
As I mentioned in my bio, the reasons I ported CGI::Application are because it uses a paradigm that fits web development, and my work situation mandates I program with PHP. The combination of the run mode == method paradigm of CGI::Application with PHP is very powerful, and makes for rapid development of reusable and extendible applications -- two qualities I find I need on a daily basis.
I really cannot make a case for using PHP + Cgiapp versus Perl + CGI::Application; it really depends on the language you're most familiar with, the server environment on which you'll be running your application, your work situation (if relevant), etc. I can make a case for using CGI::Application or Cgiapp -- and that case is made above: rapid development of reusable and extendible web applications.