I wholeheartedly agree that for web applications client side applications are the way to go and spend all day every day working on one which we are as you said going to throw on a CDN. I argue however that the experience of sending down the whole asset package (or parts thereof) just to show the login page or other assumedly tertiary screens of the application is worse than rendering that server side and sending it back lickety split. There are other use cases too, you might want to leverage Rails' ability to pump out both XML, and JSON, and maybe capitalize on how easy it is to add new formats like CSV. My point is that you lose _so much_ flexibility to do anything at all server side by ditching Rails that it simply isn't worth the performance increase until you are absolutely sure you should switch and that your requirements are stable. If this is the case it might even be time to ditch Ruby for something more roflscale.
With regards to your other comment, I again disagree. To me it seemed like you were advocating switching off Rails because you were no longer using it's view rendering bits. I say balderdash, as above, I think you will run into weird unforeseen situations which you don't want to implement client side. To your ecosystem point, indeed, decoupling progress has been made and its wonderful to see. It's great for Rails to have stellar competition, but the reason I started using it in the first place is that it took 15 minutes to make a blog. It just works. Smart people have made decisions about what ORM and tempting engine and test framework to use, and how to architect it all in such a way that my teammate and I both know where to find something to change it. I don't want to have to make all those decisions and make all the same mistakes Rails did before arriving at the happy middle ground it has, and I want my teammates to just be able to jump into my project and know how to use the thing.