Since you have root on the server, try running the script as the same user that owns the server processes ('www-data', 'apache', or 'nobody' are common) and see if you can still connect. If not, then that's where the problem lies. Since you're able to connect when running it from the CLI, the firewall probably doesn't have much to do with it.

It's also quite likely that your DISPLAY setting is coming too late in the process to matter.

Update: I just tried it out, for curiosity's sake, and it seems that you -can- set it in a BEGIN block - but you don't have a BEGIN block, you have a subroutine called BEGIN, which isn't the same thing at all. And yes, it's a permissions problem: the 'www-data' user on my machine can't connect to localhost:0.0 either. I'm not going to chase it down, but this seems like it would be a productive avenue for you to follow. :)

-- 
I hate storms, but calms undermine my spirits.
 -- Bernard Moitessier, "The Long Way"

but you don't have a BEGIN block, you have a subroutine called BEGIN, which isn't the same thing at all.

AFAIK, there's no functional difference between a BEGIN block with and without "sub".  The docs say

"These code blocks can be prefixed with "sub" to give the appearance of a subroutine (although this is not considered good style)."

Where would you think a functional difference lies?

As for the OP's problem, the issue presumably is that the www-data user doesn't have a cookie that would allow authentication with the X server.  The fact that it works via a separate ssh connection (with X forwarding) doesn't say much — it is because the ssh server sets up an appropriate DISPLAY/socket and cookie for the connection.  But that cookie can be transferred to a different account, if desired.  For this, list it from within the ssh connection's terminal with xauth. You'd get something like

$ xauth list $DISPLAY
somehost.domain.com:10  MIT-MAGIC-COOKIE-1  b412a470ac5605e443cd330f48
+bbc62e
[download]

Then switch to the www-data account and run (or run the same command from within the BEGIN block in the CGI)

xauth add somehost.domain.com:10 MIT-MAGIC-COOKIE-1 b412a470ac5605e443
+cd330f48bbc62e
[download]

and set DISPLAY to somehost.domain.com:10.  This adds the cookie to the user's xauth database file (by default ~/.Xauthority), and hence allows www-data to connect to the X server via the same tunnel that is used by the ssh connection.  Of course, this only works as long as the ssh connection is established (so you should keep it open while debugging).

AFAIK, there's no functional difference between a BEGIN block with and without "sub".

Oh - that's a new one on me. :) Thanks!

As for the OP's problem, the issue presumably is that the www-data user doesn't have a cookie that would allow authentication with the X server.

Mmm... maybe. Or it might require having the remote X server listen for the connection on 6000+; depends on how 'ptkdb' is written, I would think. Most Linux distros these days run X with the '-nolisten tcp' option, which is quite the pain to disable (I needed to do it a while back, in similar circumstances); at that point, 'xhost hostname' allows communication from the other host, etc. As I'm sure you're aware, though, this has various security implications.

(Ah, good old X, with its annoyingly-high level of access to root privileges and infuriatingly-arcane protocols. Always such fun. :)

Update: I just tried it out. On my machines (Ubuntu "Oneiric Ocelot", both ends), setting the cookie didn't help; turning off '-nolisten tcp' and running 'xhost otherhost' popped up that 'ptkdb' window right away.

Actually, I'm not very happy with that. When I get a little more time (I've got to run off to my boat and do a bunch of maintenance), I'm going to see if I can force it to work in a more reasonable way - i.e., the way you suggested - or figure out how to patch ptkdb so it works with that model, if possible.

-- 
I hate storms, but calms undermine my spirits.
 -- Bernard Moitessier, "The Long Way"