Note that Charm was not "read heavy" -- it was totally interactive and doing a lot of real work; we did live (email) thread locking and all kinds of crazy stuff. If we were to start from scratch, you can bet your ass we would keep the client-side as dumb as possible.
>client-side processing and decoupling is detrimental to both the speed of development, and application performance
I can only guess then that it was a bad design choice for this particular application and for the developers working on the project.
My own experience has been the opposite. Client side mvc has resulted in speed of development INcreasing and made various parts of application performance better. I described some of the reasons above. For example, if you have dedicated back and front end developers, you can develop very quickly, indeed!
Another point that seems particular to this project:
> Especially when you’re starting out and need to stay flexible you don’t want to have too much code around—and Rails is great for that, but… adding a JSON API layer and basically a second application that runs on the client is annihilating this advantage for you.
If building a JSON API layer and a client MVC adds significant complexity, rather than decreasing it, then it was likely a poor choice. For other products, building those decoupled pieces can reduce the complexity quite a bit. One example would be when you are creating a platform, of which a web application is only a single piece.
I'm sure it still has its place in the world, just maybe not for an app with the complexities built into Charm? .. perhaps.