I haven't heard it described like that, but in a sense I guess. At Nature (where it was developed) we use it to decouple our front and back ends. So when we work on a feature we agree on a JSON structure beforehand and work in parallel. It also gives us the ability to work in exactly the same way on the front-end no matter which back-end system is producing the JSON. This is awesome if you're a company that has applications written in quite a few languages
I don't see it solving one problem so much as lots of them.
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').
Seems to me that its purpose is to be a server-side pre-renderer for SPAs, i.e. a self-hosted prerender.io.
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.