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.

Huh? It's precisely for this reason that any serious spamassassin setup will use spamd and not simply pipe messages through to spamc. The latter will come to a grinding halt under serious load. Thanks for making my point for me ;-)

Why on earth would you need SMTP to talk to such a daemon?

You wouldn't, you could also use LMTP. But your MTA has already accepted the message, which means you need a sensible way to communicate error states back to it. If (as you say) your database is down you want to pass back a temporary error to it. If you don't want to accept the message you need to pass a 5xx. Doing that in any other way than via a mail protocol is error-prone.

Your MTA can also take care of queuing - you may get bursts of mail faster than your database can store them.

That won't work well if you're piping messages to a new process, the process will either time out or die. In both cases your MTA will (normally) create a bounce, because this is a fatal error, the MTA was unable to deliver the message. You can configure the MTA to behave differently but again, that's hard to do correctly (if you care about RFCs) and much more complicated than writing the correct behaviour in Net::Server::Mail. An [SL]MTP-talking perl daemon can just give back a 4xx or 5xx error to the remote mail server, and that server can take care of the queueing for you. Much better.

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.

Congratulations, you've just broken SMTP. SMTP guarantees that one of two things will happen to a message: 1.)The message will be delivered or 2.) you will get an error message back saying that it wasn't. If you set up a mail system to accept messages and then just blackhole them you have broken the 2nd part of that guarantee and are part of the problem email has these days. Superfluous bounces are another problem, but that can be solved by designing your system so that they do not need to bounce, not by breaking the protocol.