Because it's not subtle. In particular, once you introduce "client/server" into the pattern, you've walked into a completely different domain, with completely different problems, solutions, and patterns, and in particular you suddenly have a great deal of concern over matters of latency and bandwidth, which MVC has no particular consideration for, because the entire paradigm was built on the desktop.
Just like trying to hide network-based RPC behind the same abstraction layer as a simple function call is a profoundly bad idea, inviting a pattern of thought into your head which will encourage you to neglect the client-server component of your solution is also a bad idea. Even if you think it won't fool you that badly, why let it fool you at all? Why not actually think of it in the proper terms?
Some combination of MVC and client-server is possible, but even then further specification is required to be clear about what you're doing, because the client/server can be placed in arbitrary locations in patterns, and particularly for web environments one must be careful to specify which components of the various elements are the canonical ones, where they live, and which are ultimately just cached copies.
Further it appears to be empirically the case that people who get MVC-happy begin to mistake MVC for being the one and sole and singular definition of good design, and start sticking it places it doesn't belong, while neglecting the proper design practices that should be used. MVC is actually a brain bug; seeing someone go on about MVC is an almost 100% accurate marker for someone who doesn't deeply understand design at all, and just has a hammer and is hitting things with it.
Your reply is spot on, but wasn't the time raise this issue 7 years ago when Rails was released? Or maybe earlier if Java frameworks were self-described as MVC? To try to push Model2 now seems like an impossible task with almost no reward. It's like complaining about common usage of the word "hacker". It serves no one to take up arms, just let it be and move forward. Maybe coin a new term.
And my beef isn't the terminology issue, though I would observe that if we decide to just declare that everybody using "MVC" is using it correctly, we immediately dilute the term to the point that it has no meaning whatsoever. It's more the brain bug part.
I wouldn't want to "fix" MVC usage, we'd be much better off simply eliminating it. It's almost never used in a productive manner. As for what to replace it with, that's easy: DRY, Don't Repeat Yourself. The particular structure of the code is always particular to your local problem, rarely fits into any particular paradigm when considered as a whole anyhow, and the real design criterion is DRY. I can't quite say it's impossible to have badly-designed code that is also completely DRY, but I would imagine it must be a challenge.
Just like trying to hide network-based RPC behind the same abstraction layer as a simple function call is a profoundly bad idea, inviting a pattern of thought into your head which will encourage you to neglect the client-server component of your solution is also a bad idea. Even if you think it won't fool you that badly, why let it fool you at all? Why not actually think of it in the proper terms?
Some combination of MVC and client-server is possible, but even then further specification is required to be clear about what you're doing, because the client/server can be placed in arbitrary locations in patterns, and particularly for web environments one must be careful to specify which components of the various elements are the canonical ones, where they live, and which are ultimately just cached copies.
Further it appears to be empirically the case that people who get MVC-happy begin to mistake MVC for being the one and sole and singular definition of good design, and start sticking it places it doesn't belong, while neglecting the proper design practices that should be used. MVC is actually a brain bug; seeing someone go on about MVC is an almost 100% accurate marker for someone who doesn't deeply understand design at all, and just has a hammer and is hitting things with it.