Only if you completely discount the related costs of building and maintaining such an additional API as well as the customer service impact of basically allowing users to screw up their own key management.
Even if I concede this to you (and I don't), you've already written an IMAP/SMTP bridge that solves these problems. Open source it and make it available to free users and the problem disappears (well, is reduced. Most non-technical users don't know how to run a daemon after all, and making them put it on their own infrastructure is lame as hell).
Because running PGP software and handling key management locally is way easier than double-clicking on an installer? I don't concede that for a second. Remember that the alternative you want is ciphertext directly via IMAP, which is not at all user-friendly, which is exactly why we didn't do it.
As for the bridge, that is exactly what we'd like to do, as I've said before.
And customer support time and developer time devoted to this would cost money and represents an opportunity cost as well and that's a fact, not a point to be conceded.
And like I've said before, what you'd like to do and what you are doing are different. Nothing stops you from open sourcing it today. Put in comments that the APIs you use are not officially supported if you must. Open source it! It should have been open source a year ago! Open source it!
