The emails that moodle sends out are pretty vanilla, even the ones which are html. Even if you've gone to to effort and expense of implementing a custom theme none of this makes it into the emails.

The current general approach in core has been to slowly move some emails over to using templates but this just moves the problem and it also pushes the burden onto the themers to tweak lots of email specific templates rather than 'email theme' specific things.

The other problem with the mustache templates is that they are assumed to be 'web html' when what we need is 'email html' so we can't easily reuse the templates.

 What I see as the best code reuse and most flexible and them-able is where each email is written as a renderer method which is given an output renderer. So instead of each part of moodle manually constructing an html and a text version of the email it would be more like:

function render_password_confirm_email($user) {

    $html = '';

    $html .= $this->output->heading(get_string...);

    $html .= $this->output->greeting(get_string...);

    $html .= $this->output->notification("...", 'notifysuccess');

    $html .= $this->output->single_button(get_string...);

    $html .= $this->output->support_signature();

    return $html;

}

and then we would have a htmlemail renderer and a textemail renderer and we can just call the same code twice to produce both email parts in a consistent way which reduces the burden on a dev to do this well. The majority of the render methods could be reused from the web renderer and would include things like image_url(), user_picture()

At the moment this is all just a single lang key in the example above:
https://github.com/moodle/moodle/blob/master/lang/en/moodle.php#L646-L662

The 'textemail' renderer is actually very close to the core_renderer_cli which renders things like headers into ascii art:
https://github.com/moodle/moodle/blob/master/lib/outputrenderers.php#L4759-L4769

The htmlemail renderer would reach into the web theme (which could also be per-user or course etc) and pull out things like the .btn scss style variables and bake those into email compatible inline styles. This will have a dependency on boost, which complicates things because we'll need a simpler fallback renderer for non boost themes. 

When it all comes together it will mean a button in an email for person X looks mostly like a button on the web, for that exact person and the theme they are using. The primary things I think we want are inheriting the active boost theme's typography, buttons, notifications / alerts, and secondary things are crumb trail, badges, cards.

This pushes the bulk of the complexity and implementation into core, and most custom themes will get pretty decent emails out of the box which match the web.