5. OO always to be used where possible

For CGI scripts, I don't see the point. Most CGI scripts are going to have around 100-200 lines of real code (not including the stuff that is just outputing HTML). While using OO-based modules is a good idea, it seems like overkill for the script itself.

17. Assign CGI parameters to hashes
...
23. No Global Variables

OK, let's give the mandatory "Global Variables are Bad" (tm). Fine.

In CGI scripts, I prefer to put options passed to the script in global vars. Every function can get that information anyway, we just make it easier this way. Each of my scripts has a set_params() function that is the only function allowed to change those global vars. Example:

use CGI qw(:standard);
# Other modules

my ($param1, $param2, $param3);

sub set_params 
{
    $param1 = param("param1") || 0;
    $param2 = param("param2") || 0;
    $param3 = param("param3") || 0;
}

set_params();
# Whatever other code you want
[download]

(I rarely use the fancy features of CGI.pm, so I usually don't bother with the OO interface, though I probably should).

The problem with putting them into a hash is that you take away many of the benifits you get from "use strict 'vars'".

7. No hardcoding of values especially file paths, script names etc
8. Config files or config scripts to be used

How do you get the config file without hardcoding the path to it?

Update: For config files, I suggest being very careful with absolute paths. At my job, we recently moved to a new server, and we had a lot of problems with scripts that were using absolute paths that were no longer available on the new server. Additionally, our test server had some paths to the server's directory that didn't exist on the production server, which broke even more stuff.