Alex: That assumption does make some sense. I wondered about triggers completely being missing by default compared to earlier versions of the plugin.
However, I don't get where this leads to adding an 'Always' trigger by default. If it were 'Unstable' or 'Failure', it'd be just as obvious what the behavior is (and users still can customize the triggers to fit their needs, like removing the default trigger and adding the 'Always' trigger) – but it'd match what users might expect is the default coming from built-in Mailer. That's what I was referring to.
Please re-consider this particular choice of the default list of email triggers. I'm sure it'll lead to a lot of unintended 'spam' from carelessly set up instances – Failures, you can argue are important, but successful build notifications? (FWIW it might actually make sense to make the default list of triggers added to new publisher instances configurable globally, similar to default email contents and content type)