I can't think of any reasonable use case. Grab little NPM ditties and incorporate them into your Go binary - Javascript to Go becomes as Lua is to C? Somebody enlighten me.
Edit: Not that this needs a use case per say, just that the intent behind it is underspecified enough for me to wonder about it.
Duckduckgo goodies[2] also a good example of what we've been doing.
Imagine a highly dynamic web page, beyond the initial page load when you interact with the page javascript executes the user's actions then rewrites large chunks of the page. As a developer, you need to write code on your backend that knows how to render the initial HTML for the page, but then you have to duplicate this functionality in JavaScript since the client needs to be able to render any chunk of the page that changes in response to a request.
You have a few options as a developer here. You can live with maintaining two code paths in different languages that do essentially the same thing. Or you can get rid of the backend rendering entirely, making your page less friendly to no-script users and web crawlers (and sometimes making the site flicker a bit as content gets loaded initially for all users.)
Or you can use shared code on the backend and the client for rendering HTML by having a backend that speaks JavaScript.
This project may not be the fastest JS engine or the one with the most features right now, but if nothing else, it's a really nice project for learning Go and writing interpreters.
Maybe some new ideas will be explored in this engine first, because it's faster to implement them in Go than in the (huge) V8 or other JS engines.
Having new alternatives to established software is always a good thing.