I've done all three options you present. I disliked (1) because (a) you can't necessarily count on hits to your website occurring, (b) your web server process could fail, which means it wouldn't be run, and (c) it adds extra overhead to your CGI process, thus slowing it down for the user.

I use (2), cron, frequently, and use it for many things. However, I've also had cron fail on me (and I haven't been able to get it back on the system where it failed, further compounding the issue), as well as have new cron-spawned processes collide with previous cron-spawned processes. Regardless, cron is my favorite option of the three you present, especially when you need worry about neither flexibility of schedule nor collisions.

I use (3) currently for a process that monitors servers. It's more flexible than cron, but it takes more resources (for instance, it needs to spawn the perl engine).

If you want to go the route of (3), your own daemon, it's actually very simple to do in perl, and not terribly resource intensive, if you use the Proc::Daemon module. It's as simple as:

use Proc::Daemon;
Proc::Daemon::init;

while (1) {
    # do some code
    sleep 60; # wake up every minute
}
[download]

If you don't want to worry about the process dying/crashing and not restarting, add a line to your /etc/inittab:

MD:2345:respawn:/path/to/script
[download]

where "MD" is a unique identifier for your daemon, and 2345 indicate which runlevels to start your script on.