I can see the value where you would need to fire email alerts from different parts of your stack, and have a central place to control and config them.
What happens next, for example, when you need to send alerts from frontend events? Or from other non-Rails parts? Duplicate code and logic?
Every email client in the world except Gmail (yes, including Outlook) supports, to some extent, CSS in tags in the head section of HTML emails. Gmail is the only client in the world that does not, and only supports inline CSS.
As such, while being a very popular client both on the Web and on Android devices, Gmail forces anyone who wants to send HTML emails to try and find workarounds, in order for emails they send to look good across all clients and devices. In effect though, there's no real solution for sending an email that looks good across all devices, while not resorting to very small-fixed-width emails, if you wish them to look good (and then making them not look good on big screens, Web and desktop clients).
And while other clients have their quirks (like Outlook using Word rendering engine), almost everything is possible to achieve with them, including responsive HTML email designs, because they support CSS in the head section of the HTML. Just as a comparison, iOS supports CSS to a maximum degree, including media queries, a fact which makes email templates easy to code and handle, and brilliant to view across iOS devices.
I hereby call upon Google to get with the program, and start supporting non-inlined CSS in emails. If AOL and Yahoo can do it, you can too.
I think the discussion comes down to which option you ultimately prefer -- 1) be in full control of your stack, having only yourself to criticize, and having to deal with all the devops action that comes with it, or 2) let heroku deal with the underlying while you focus on your app, as their promise suggests, and suffer (also financially) from time to time due to faults like this.
Everyone has their own reasoning on this decision, and that's ok. I think that the voices here saying "I won't start my project on heroku because of this" are not thinking this through. I think that for any project starting up, focusing on app rather than infrastructure is much more important than routing issues.
I'm not bashing them, I'm only saying it merely shows that although event/action tracking is a great approach, "traditional" traffic analytics are still needed.
I'm not a rubyist, and I can see how this can be nice for ruby developers, but IMHO, if you need javascript - use javascript.
Why add another layer of complexity and error proneness?
What happens when a different js programmer needs to review your code? Or when you need to write some Node.js code and forgot all about syntax?
"The main motive is to have a decent standard library for JavaScript" - jQuery works just fine.
How many times have you looked at your metrics charts, saw some peak or trough, and couldn't explain the reasons?
To help better understand charts, I released a tool that overlays business data on them. Everybody's business is different, so anybody can track any events they want, internal or external (internal like infrastructure changes, version roll-outs etc., and external such as oil price, major news events etc.)
Also, data layers can be public, so for example I prepared a simple Google Panda Updates events layer, that you can overlay and see how your website traffic was affected. Another example is the US Holidays layer.
Currently it's available as a Chrome extension, and overlays charts on Google Analytics and Quantcast. The plan is to be able to overlay in any browser and on any chart, but before that happens, i'll be happy to get your feedback.