MVC - simplified?

  When is it sensible to simplify MVC for small GUI applications?

  What about the following simplifications:

  * Do not de-couple the model from the view via the observer
  pattern in cases where the view and model are quite fixed,
  so that no pluggability for the view is needed: The model
  knows the view and calls the view directly when needed.

  * Do not formally separate M, V, and C into separate
  classes or packages, but use a single big ?monster class?
  for the main program that contains M, V, and C. (However,
  comments or methods might be used to indicate which parts of
  this class belong to the realm of M, V, or C.)

  The advantage of this approach is that it saves the effort
  for the specification and implementation of interfaces and
  the administration effort for the registration and
  de-registration of listeners. It does not exclude a later
  refactoring that than will implement more separation and
  decoupling, when needed.

  And regarding monster classes: It might sound provocative:
  I am aware of a 64 K limit on method size, is there a known
  limit on class size (like at most 100 methods, or or some
  such)?

  BTW: Did the pattern ?MVC? actually ever require that the
  model, view, and controler are separate objects or classes,
  or does it also allow for them to be mixed within the same
  object or class - or even the same method or statement?