Thank you for posting that checklist, that's a vital document for any spam planning.
SpamAssassin, executed through procmail on the mail client's email, is indeed resource intensive and does not scale well for an organization. Other people have mentioned other upstream filtering techniques, such as grey listing and DNS blacklists, but those are limited because of the large numbers of zombied Windows clients around the world, which have their resources rented as botnets to send spam from legitimate environments around the world, partly to evade these filters.
My experience is that spam requires management, not silver bullets. Layers of defense such as supporting SPF, which filters very early and cheaply based on DNS records, helps eliminate most forged gmail.com and hotmail.com and other large domain phishing. More powerful, more expensive filters such as SpamAssassin can be applied on the vastly reduced volume of email that gets past the earlier filters. Unfortunately, if you're processing with a local "procmail" by pulling the email from the mail server to your local machine, it's already too late to activate DNS blacklists or SPF, so the increasing burden on SpamAssassin is predictable.
I'm afraid I don't have a great solution for the original poster except tp push the filtering upstream, to the mail server itself, to reduce the load with those lightweight filters such as SPF or blacklists.