How can it be a good thing to follow the MVC framework on both the client side and the server side, as it says in it's philosophy, when the client side is the V in MVC?
Because then it's not really MVC anymore. It's something else, perhaps inspired by MVC, but not MVC.
The web world really needs to get over its juvenile idea that MVC is the One True Architecture and if something isn't MVC it isn't good and therefore if we want to present a new library with a new design it is Mandatory to explain how "No, really, it's MVC! Even though it isn't, here's how it is!". It's not MVC. That's fine. It's probably better. Many designs are. MVC is fine in its niche but that niche doesn't cover Every Web Application Ever very well.
However...
> Because then it's not really MVC anymore. It's something else, perhaps inspired by MVC, but not MVC.
I fail to see why the example I gave does not follow MVC. You have MVC on the server (as people have been familiar with for a very long time. Nothing new here). In turn, that data produced by the view on the server (could be HTML, XML, JSON, whatever) can form the model of a second MVC architecture on the client side.
What exactly isn't MVC in either the client or server? The only thing I can thing you might take issue with is consuming the model from the data sent from the server, but I couldn't explain why. This is still in keeping with the MVC pattern, which in no way prescribes that the data has to come directly from a database (or whatever else the server's model's state is formed by).
Or is the problem with the server's view not generating output that is necessarily HTML to be looked at, but data to be further consumed? Again I don't see how that doesn't fit in with the MVC framework.
MVC makes sense for a pure Javascript app that uses the server only as a DB server (if that). It can at least be jammed into a classic old-style pure server application. But if your app actually spans the two, you haven't got MVC anymore... or you've got an app scoring 8 out of 8 on the network fallacies, probably by virtue of trying to wrap all network access behind an "RPC" interface, which tries to represent network interaction as local function calls, which one of the easiest ways to score an 8 out of 8 on the fallacies list.
Because of the way MVC tends to afford glossing over the network fallacies, I tend to consider it an inferior design for almost any web application. It's a lot of code busywork to try to sort of kind of (probably not actually, assuming the MVC one is starting with is even MVC in the first place and not just "vaguely MVCish in name only") conform to a particular architecture, requiring at least three moving pieces to do anything (one in each letter of the acronym, in practice, often a view on the server and on the client) mandating that your application be flung out all over the place, and it gives you... hardly anything in return, really. Certainly nothing that a direct application of DRY couldn't have given you. It isn't necessary for most web apps and it's a terrible default for a new web framework to impose on its users.
While I'm not a fan of the "hexagon" name (the number "six" doesn't seem to have any meaning, except this guy once drew a diagram in a hexagon), it's a much better way of looking at things. I tend to think of it as a celluar design; there are the cell innards, then surrounding it is a cell membrane that is responsible for cleaning up the innard's view of the outside world, and exposing well-defined capabilities to the outside world. (The metaphor is not perfect; biology is messy, and there's no compelling reason to copy that aspect. But the general idea of cells, or hexagons, is quite powerful.)
One of the interesting aspects of Haskell is that it tends to enable the creation of a lot of very fine-grained cells, where the type system is helping you build a very strong and very well-defined membrane; it allows you to see even things as simple as "map" as fitting in to this model, at the smallest level.