For a lot of dynamic languages, at least, the templating engine is a surprisingly large portion of your page load times. I wish I could bring up the breakdown I saw a while back, but it's certainly non-trivial in many cases.

Sometimes it's fun just to make things better, faster, stronger. Hard to find a downside to having your template engine faster.

I have no experience with Ruby template engines, including Crustache and Mustache, but of course it matters about serving clients 40x times faster. 800ms to serve me what could be had in 20ms? Amazon, Google [1][2], and others have talked extensively on speed-to-conversion ratios.

In Python land, there have huge improvements in template engines [3]. And they are not done; Jinja(2) author, Armin Ronacher, is working on a Google Summer of Code (GSoC) project [4] to speed up Django and Jinja2 templates.

[1] http://googleresearch.blogspot.com/2009/06/speed-matters.htm...

[2] http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....

[3] http://stackoverflow.com/questions/1324238/what-is-the-faste...

[4] https://www.djangoproject.com/weblog/2011/apr/25/gsoc/

A (niche) use may be to compile for NativeClient, to provide better responsiveness if you're doing large templated live-previews (though admittedly this is more sensible with formatting like markdown rather than templating).

IMO, another nice side-effect of having library code in C is portability and easy code reuse, since lots of scripting languages can interface with it.