This is vastly more resource-intensive than having a perl daemon that already runs with all required modules pre-loaded.
If that were the case, all the setups that use spamc to talk to spamd (client and daemon of spamassassin) would come to a grinding halt. But that's not true. A light weight program talking to a daemon doesn't have to be resource intensive. If it's run very often, it'll be in memory anyway. ;-)
Of course, you could have a perl daemon running and have qmail send the message to that, but what's the point? You need to use a mail protocol for transfer between qmail and the daemon, so it's no less work to write and you might as well leave qmail out of the process entirely.
Why on earth would you need SMTP to talk to such a daemon? That what your MTA is for. Your MTA can also take care of queuing - you may get bursts of mail faster than your database can store them. Or your database may be down, and you still want to accept mail.
You also have the problem of what to do with messages your perl process can not or does not want to accept. If there's an intermediate MTA, rejecting the message will create a bounce, which may be superfluous. Running your own receiving daemon you can reject at SMTP time which means it's up to the sender to create a bounce or ignore.
Whether or not the MTA will create a bounce that depends on how you configure the MTA, or on the exit status of the delivery program. I can't answer whether there should be a bounce or not - that's up to the OP. I often set qmail systems up in such a way that they never bounce. They accept anything, and just deliver to /dev/null instead of bouncing. There's already enough spam. ;-)
Anyway, as I said, it's my personal preference. I like qmail, it does its job well and efficiently. It's really easy to configure, and I haven't encountered the resource problems you refer to in the beginning of your post.
