If you consider leaving OLE Automation procs off a benefit, then yes, I agree. Of course, that all falls into whether you have a properly locked down system or not.
The lock down is only one aspect of it. Given its bad reputation and the fact that its disabled by default its not an option in some corporate environments. That is not a commentary on the tool itself, rather on the people that have misused or abused it. I prefer not to have it available in case any of these people happen to make their way into my environments.
I need to double check on the asynchonus part.
An interesting side note on this behavior. One thing that frustrated me when using cdosysmail long ago was if the mail server was down the email attempt would fail. This meant that I either needed to build an email infrastructure to queue my messages and send them later, i.e. develop something similar to Database Mail myself, or take the risk of a process erroring out because an SMTP relay was not available for one reason or another. Personally I welcomed Database Mail with open arms.
One advatage that I've found with CDOSysMail is that (according to the infrastructure team where I work) you don't have to make any special setup in a clustered envirionment like you do with Database Mail. To be absolutely honest, I trust those folks and have not done a deep dive to find out what they meant. I'll try to find out more on that subject.
Database Mail is cluster aware so maybe they have to give it special attention to set it up as a clustered service. They still have to install the cdosysmail COM object and configure the SMTP relay, and on all cluster nodes. I am not sure how they could be getting around that one. They may have made it part of an OS image they use as a base install, but it had to be configured somewhere. You can essentially get to the same place with Database Mail using a T-SQL script that can be run when the instance is brought online. I have one that is part of my base install steps. The script is setup to be runnable against any instance. I guess it depends what people think are easier, for them, but I myself have not known Database Mail to be a PITA and never had an issue with it, although I have not administrated it in a clustered environment. For the two clusters I've worked on, I did not have to mass with Database Mail.
Another advantage is that I've found that Database Mail won't necessarily send to the outside world (send alerts to my private email, which I check more often, and to certain support vendors) whereas CDOSysMail will send to anyone you need it to.
That is most likely a limiting configuration in your SMTP relay, or somewhere downstream. Database Mail has no such restriction. Not only does it not have an issues sending email to outside addresses, you can configure Database Mail to use an outside SMTP relay as well, e.g. to use your Gmail or Live account so for testing from home I don;t even need to setup a separate SMTP relay. How to configure SQL Server Database Mail to send email using your Windows Live Mail Account or your GMail Account
Of course, I love for each proc to be able to fill out the FROM on the email without me having to setup a special config for each proc.
I agree, that is annoying! In SQL 2005 you are stuck with creating a new profile for each from-address. I was disappointed Microsoft left the ability to override the profile's from-address out of the initial release. They added support for from-address and reply-to-address to Database Mail in SQL 2008.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato