With a decoupled front-end you can make applications which are much more flexible for dealing with change. Imagine swapping out the entire backend application, or completely re-writing the front-end - you can easily do either since the integration between the two is formalised and documented by the json contracts.
That also means a new front-end developer can clone down a Shunter application and start modifying templates with confidence it's not going to break anything without having to run the backend, services, mock db, etc. Great for working in big teams, or ones that aren't co-located.
It can also run a single unified front-end across multiple backend applications (for example if your rails application wants to share a common layout etc. with your Wordpress-driven blog section, or whatever ecommerce backend is driving your 'shop').
Might also be cool if you're running a WordPress site and you want the front-end to be an SPA, but you don't want the SEO/page speed hit. Just use WP-API and plug it into Shunter.
I do understand the use scenario. I've done some sites with this same model using Prismic.io as the backend. It's a nice customizable CMS-style system that provides JSON APIs, which a Node.js app then translates into HTML (basically just filling out templates with data selected from the JSON). This has worked well and I've been really quite happy with Prismic.
So it looks like I could be using Shunter for this scenario, but I'm not sure what the benefit would be over my hand-rolled Node apps. Can someone illuminate?
In terms of benefits of using Shunter over a home-rolled solution, the same question could/should be asked of any framework. Shunter is very well tested, has been used in production on a large site for a number of years, and is used to serve hundreds of thousands of requests. It will also be supported by a large development team for the foreseeable future.