Vamos lá:

“Fiquei meio confuso quando você disse que MVC não são camadas e sim uma maneira das camadas conversarem.”
Vamos melhorar essas definições. A Arquitetura de Camadas nada mais é do que uma proposta para dividirmos logicamente (ou até fisicamente) os componentes de um software. Ou seja, deve-se agrupar os componentes que tem responsabilidades em comum a fim de promover um maior nível de coesão da aplicação. Não confundir o termo componentes aqui com objetos visuais, mas sim tudo que diz respeito a classes, funcionalidades, etc. Todas as “ilidades” desse tipo de implementação todos já sabemos: Flexibilidade, manutenibilidade, reusabilidade entre outras. No entando a arquitetura de camadas não define COMO essas camadas se interligam ou interagem e isso leva, muitas vezes, a sistemas altamente acoplados onde as camadas se conversam como bem entendem utilizando componentes ou sub-componentes umas das outras. Geralmente o tipo de gráfico usado para definir camadas, principalmente 3-camadas (3-tier) é linear e a camada de Negócio fica entre a Apresentação e Dados. (não esqueça essa arquitetura pode ser 1-tier, 2-tier, 3-tier ou n-tier).
O problema começa quando essa integração entre camadas começam criar um emaranhado de fluxos que acabam prejudicando o software de maneira geral. E isso tende a piorar quando existe uma interface gráfica no meio da história, que hoje é comum mas que quando foi criado o MVC, meados de 70, não se falava muito em GUI (Graphical User Interface). Ainda tem muito assunto pra tratar aqui, mas vamos continuar.
Para reduzir os problemas de alto acoplamento entre as camadas foram (e estão sendo) criados alguns Design Patterns. Na verdade não foram criados e sim “descobertos”, alguém desenvolvia um bom padrão ali outro aqui e foi-se documentando tais sucessos. O MVC nada mais é do que um conjunto de Design Patterns integrados, trabalhando em conjunto para reduzir o acoplamento e melhorar o desenvolvimento e integração das camadas de software. Entre esses padrões se enquadram o Observer e o Strategy (vide Head First – Design Patterns). Esse modelo que atua em cima das Camadas (não necessariamente 3-tier) propõe um gráfico em forma de triângulo (vide http://java.sun.com/blueprints/patterns/images/mvc-structure-generic.gif ) onde existe uma “norma” de integração onde o Controller faz solicitações ao Model, sendo que essas solicitações provém ou não de uma interação com o usuário e o Model por sua vez informa sua mudança de estado (se houver) ao View, que no caso observa por mudanças no Model. Só isso. Existem pequenas diferenças no modelo MVC de acordo com a necessidade, mas o mais comum é a View e o Controller ficarem na camada de Apresentação e o Model na de Negócios. Esse modelo é o mesmo do MVC do Smalltalk e não é o mesmo usado hoje nas aplicações Web. Em algum lugar vc citou “E eu achando que MVC era pra web apenas”, na realidade é totalmente o oposto, pois na década de 70 desenvolvimento web sequer era discutido. O modelo atual de MVC implementado na web é o que chamam de Model-2 (na verdade isso é meio contestável, já li em outros lugares que Model-2 é outra coisa), pois na web não tem como implementar o pattern Observer e isso tem que ser feito de outra forma, no caso usando um Front Controller.
Abaixo seguem algumas referências:
http://java.sun.com/blueprints/patterns/MVC-detailed.html
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
http://en.wikipedia.org/wiki/Three-tier_(computing)

“o framework MVC deve possibilitar que eu possa no controller ou na view fazer chamadas a métodos privados do meu model, certo?”

Mas o objetivo dos métodos privados e não serem visíveis por nenhuma outra classe.

“(modelo)Tarefa, dentro dessa classe tarefa eu tenho o método criar.”

Naõ entendi bem. A classe tem um método para se criar uma instância de si mesma?

“Por isso que eu disse que o framework deve permitir a conversa entre as camadas.”

Claro que permite, em momento nenhum eu disse o contrário. Porém ele aconselha que seja seguidas algumas regras para isso.

abraço.

Danilo G. Magrini
Marília / SP

Abraços.