I agree completely. Rails actually is useful as rails-api, but the real benefit to Rails is the simplicity you get from the integrated development system.
You lose a lot of that when you go away from Rails and start using a JS based front end. It's not that rails-api doesn't work - it works quite well. It just neutralizes, to some extent, the productivity gains you got from rails.
Here's a quote from the rails doctrine that sums it up nicely: "Rails specifically seeks to equip generalist individuals to make these full systems. Its purpose is not to segregate specialists into small niches and then require whole teams of such in order to build anything of enduring value."
I actually think Rails is still an excellent choice for small to medium business apps implemented as a series of web forms backed by a database. The productivity Rails brings in that case is pretty amazing. And you certainly can bring in a bit of javascript in a progressive development fashion and maintain simplicity and order.
What drives me nuts is when people write an SPA to stand in for a set of web forms, with almost no gain, and a huge increase in complexity (and drop in productivity). Sometimes I get the feeling people on HN are working on more cutting edge stuff. Truth is, an awful lot of business software really is a series of web forms persisted to a database. I do think you can get these apps done with half the staff, twice as fast, with better code clarity, stability, and test coverage, by sticking with Rails. In fact, the slowdown in Rails activity is probably a good indication that you should use it for these apps, not that you shouldn't!
I also really like your comments about an integrated front-end SPA (or other client-side heavy) framework. I don't see javascript having quite the clarity of ruby on the page, but it could be tidy enough to be no problem. I do think something like this will emerge, eventually.
Until then, I'd be tempted to stay with older technology. Remember the churn around spring di, pico, struts, struts 2, spring mvc, hibernate, JPA, ibates, stripes, tiles, etc...? Or, ahem, EJB? All(some?) were good frameworks written by intelligent people trying to provide value (and, in many cases, providing that value). But I wish I'd just stuck with slightly more vanilla jsp/jdbc/servlets + cookbook for a while longer. Why? Because after investing a ton of time and mental exhaustion into those frameworks, I ended up using... Ruby. My guess is that something similar will happen in the current JS chaos. Something will happen that addresses what these frameworks seek to provide, but how it happens will also be somewhat unexpected (though if I had to make a guess, I'd bet on some sort of isomorphic javascript, with a transpiler that allows people to use Python, Ruby, and other languages, breaking there JS monopoly).
Just because you see an expiration date on the milk carton doesn't mean you can't drink it for another week. My guess is that my time with Rails will be up before too terribly long, but that doesn't mean you need to start writing javascript-heavy SPAs now.
Unless, well, you do have to. Unfortunately, my guess is that a lot of people writing this code aren't doing it because they're on one of those projects that actually really needs it (or benefits substantially from it). We have to do this because our orgs require it, a software architect said it should be used, or because we know we won't get hired for our next gig without this experience, so we bring it into our current project even if it isn't helpful.