For me, extraneous double-quotes as in --send-mail-level="all" result in no email sent, so please remove those if they’re still in use (possibly good advice for any value that you’re typing into the web UI).
You might have noticed that email is sent or not sent after the backup. This is because the backup result generates an unquoted word such as Unknown, Success, Warning, Error, Fatal which is matched against given --send-mail-level component(s). A special-case word is All, again unquoted, which is how send-mail supplies it, therefore it works. If yours is still quoted, it can not match, therefore no email will ever be sent.
What this doesn’t explain is how a job that fails to send mail at “Run now” does so clicking “Commandline”, however it’s conceivable that your quoting gets removed somehow. For me, I just get the same non-email.
The --accept-any-ssl-certificate option is listed on the dropdown only on “Configure http requests” so that possibly explains why it’s not accepted. Are you using a destination that uses http? Although mail sending frequently uses the same sort of SSL/TLS encryption that http uses, its code can be entirely independent.
Q: Why do I get The remote certificate is invalid according to the validation procedure when I try to Connect? from MailKit (which Duplicati uses) looks like a similar way to ignore errors, but Duplicati doesn’t support it. Things are probably OK in SSL/TLS. Updating Mono helps, plus you’re sometimes able to send the email. When you’re not able, it looks superficially like it’s not wanting to even try, thus I point at --send-mail-level.
In addition to quote removal and certificate-acceptance setting removal, you could see if you can get http notifications to work, e.g. to https://www.duplicati-monitoring.com/ and in addition to possibly adding clues, you’ll then have an alternative notification if somehow we can’t get direct email from Duplicati working well.