Privacy on the cloud isn’t exaggerated at all. It isn’t just how the company will handle the data they have access to, but also how it is secured, how it’s retained, and what the risk of data theft would be in case of a breach. Breaches happen to everyone! We have to assume it could happen to us in how we design things.
Passwords are a little different than most data besides. Proper security standards for email services on the cloud are not to store the password, but rather a hash of the password - a unique number or string that is generated from the password, but which cannot be reversed to find the password. When you enter your password on a properly secured website, the password field is hashed, and then the hash is compared to the hash that was stored. If they match, then you entered the same password. At no point should the email server store the password itself. (Some do, despite security best practices, but that’s another topic.)
Meanwhile, cloud-based password managers use encryption to store data. The encryption password is something only you know, and without it, the data cannot be unencrypted. Once again, the cloud never stores the password(s) in plain text.
The trouble here is that for Mailspring to offer server-side send later, we would have to store the password itself on the server in plain text. We cannot use hashes, because Mailspring has to be able to send the password, and we cannot use the password-based encryption described above, because the whole purpose of the feature is to send the email without the user’s intervention (e.g. entering an encryption password). Some piece of the puzzle to access the password has to be stored in plaintext, meaning a data breach (which can happen to anyone) could expose email passwords. This is what we want to avoid.
The most secure technique would be to encourage use of app passwords when using Server-Side Send Later, as those are easier to rescind in case of a data breach. However, not all email services support app passwords, and it’s not really possible to know whether one is in use or not.
Long story short, this is why this isn’t an obvious feature. We have to consider the security implications, and ensure that there are enough users willing to accept the significantly higher risk of email data breach, just to offer this.