Declude can still be immensely useful in controlling Spam. We use it on our servers in addition to many suggestions that Bruce gives in his Anti-Spam document. It gives a lot of flexibility to fine-tune how you detect and handle Spam (and Ham to reduce false-positives). We also use it for our own custom Filters and home-made RBLs.
The downside to Declude is that it does require configuration. In addition to the .CFG files (Declude, Global, Hijack, Virus, etc) many of the Filters (.TXT files) need manual configuration as well to tailor them to your specific needs.
The other downside to Declude is that it is a CPU Resource hog, and it is not unusual for it to stay at a steady 99% CPU (no matter how much horsepower you have it will use all that is available to it). I would strongly recommend not running it on the same Mail server that is providing Web Services/POP/IMAP/SMTP to your customers, but using it with a SmarterMail Free Edition on a separate server as an Incoming Gateway.
Lastly, you need to actively monitor your \Spool\Proc folder with a Scheduled Task and script. During high volumes of incoming email (Spam Storms such as before Black Friday/Cyber Monday, Valentine's Day, and Mother's Day) it is not unusual for Declude to fall behind, causing a long delay in email being returned to the Spool for delivery (sometimes a several hour delay). When the \Spool\Proc folder gets too many messages queued we have a script that automatically moves everything to the Spool, skipping Declude checks until the mail load returns to normal. It only happens 3-4 times a year but it's enough to cause concern.
With those caveats in mind, we find Declude to still be very useful despite development being non-existent. It gives flexibility that is still not available in Smartermail and still is a useful tool in fighting Spam.