A better conclusion perhaps would be to distinguish "stateful MVC" from "stateless MVC"?
But that said, the fact that Rails (and Pylons, etc) called themselves MVC has rendered any definition meaningless, so it just kind of doesn't matter. Truth be told, it was already getting there long before web frameworks entered the picture when Java coopted the term to mean something it didn't in the 90s.
I prefer to use different terminology to avoid confusion, but if you wanna keep using "MVC" for your own stuff, I'm not going to fight city hall.
Wikipedia credits Trygve Reenskaug with inventing the term "model-view-controller", he was a Smalltalk guy with Xerox at that time - I don't think there's any relation in the origin of that terminology to the notion of a "database view" - otherwise not sure what you're referring to here (here's a link to the original paper: http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html)
(Edit: if one cares about design patterns at all, that is. Otherwise it makes perfect sense to use MVC as the marketing term it has become and do whatever)
That the model isn't notifying the view through an event system is splitting hairs. The GOF book is much maligned I think because people insist on taking each pattern completely literally down to the last detail. GOF's pattern (GOF didn't create it but they discuss it on page 4, I thought I was crazy until I just checked just now) is specifically "MVC, and because we only know about C++^H^H^H Smalltalk graphical libraries and not very much about stateless HTTP systems yet in 1993, the model notifies the view of changes too, how else would it work ?" IMHO. It's an implementation detail, it's not the essence of the pattern.
So if a JS framework is now doing MVC that includes the concept of "model notifies the view", sure call it "classical MVC" or "model-notify-view-controller" (MNVC). Shrugs.