This might be an interesting goal to work towards, but I'm not convinced that one actually wants to achieve it. I'm skeptical that abstracting away the boundary between client and server is a good idea. Unless you're a DRM true believer, there will always be an essential difference: The server is (more-or-less) guaranteed to be running the code you wrote, and the client is not. In the end, unless you are comfortable with allowing an AI to dynamically adjust your application's attack surface for you, you'll always want visibility and control of what gets done where.

SEO works fine because the page can be rendered entirely server side.

Are we missing the point that web-based applications and web pages have totally different semantics? The major difficulty with getting Google to index my single-page application is not the need to run multiple rendering engines. It's that Google indexes web pages, and my application is probably not built out of web pages -- not without a great deal of creative thought, anyway. Try to imagine an iOS application that could be fully rendered for Google. How would you do that? Does each possible window and window state get a URL? How should Google index the little popups that appear when the user executes a three-fingered leftward swipe with a twist?

The reason why you're writing your views and rendering twice is probably that you need to design them twice. You can either make your users view your app as Google does, as a series of HTML pages at distinct sensible URLs with a minimal amount of Javascript sprinkled on top (which was good enough for 1998, and even 2008, but perhaps not good enough to compete with iOS long-term), or you can design a glorious GUI experience for your users that is largely opaque to Google, or you can do the work twice: Figure out one view of your data that appeals to humans and another that appeals to indexing bots. And that job probably can't be done for you by some magic framework. Figuring out sensible views of your data is design work, for humans.

A departure from the routing paradigm found in Rails, Sinatra, Sammy, and Backbone. The traditional one URL maps to one controller action routing table no longer applies.

We didn't converge on this routing paradigm arbitrarily. Among other considerations, it is very strongly influenced by Google, a company that literally pays you money if you design a URL scheme that can be usefully interpreted by Googlebots.