$SERVER, confesso que fiquei um pouco confuso com o seu ponto de vista. Primeiramente você diz que utilizar os JavaBeans na camada de modelo (classes que contem os atributos espelhando o que está no banco de dados) é uma prática ultrapassada, porém, logo após você se contradiz, dizendo que realmente não daria para agregar a uma simples classe de entidade todas as responsabilidades de gerenciamento de conexão, transações. Sendo assim, não seria nem uma coisa nem outra? 
A meu ver, isso de “Usar JavaBean está ultrapassado” não procede. Com que base você afirma isso? Considerando um projeto com ORM, utilizando por exemplo Hibernate, temos uma distribuição ideal de responsabilidades em que a “Entidade” (JavaBean) contém os atributos, os respectivos mapeamentos e também algumas named queries, que de certa forma fazem o papel do active record para busca/leitura, mas na minha opinião seria inviável adicionar métodos salvar, atualizar, remover, numa entidade em um projeto com essas características.
Em contrapartida, a utilização do DAO ou não ainda divide opiniões, visto que o próprio framework de persistência oferece uma implementação do EntityManager, que de certa forma já funciona como um DAO genérico. Sendo assim, pra mim, os DAO são totalmente dispensáveis, eu costumo trabalhar com um DAO genérico que é acessado diretamente pelos objetos de negócio (SessionBeans EJB). Para não ficar um acoplamento tão grande em relação a tecnologia (SessionBeans injetando diretamente o EntityManager), pode ser criado um SessionBean que será o DAO genérico e irá injetar dentro dele o EntityManager, assim caso você queira trocar a estratégia de persistência, bastaria trocar a implementação do DAO genérico.
Outra coisa, sobre a divisão de pacotes, citada pelo nosso amigo rlanhellas. Eu não sou muito fã de dividir pacotes dessa forma, especificando “dao”, “bean”, “bo” etc. Imagina só um sistema com 100 entidades e 150 BOs. Você vai ter uma infinidade de classes dentro de um mesmo pacote. O que eu costumo usar é separar por módulos, que conversam entre si através de interfaces. Por exemplo: módulo de autenticação tem pacotes com suas entidades e BOs, módulo de gerenciamento de pedidos, módulo de gerenciamento de produtos, etc, etc. Quanto mais você dividir e componentizar sua aplicação, melhor. Então nesse caso, a dica que eu dou é: evite os pacotes genéricos demais. A nao ser que a aplicação seja extremamente pequena e focada.
A divisão de camadas que costumo usar é, por exemplo:
Módulo Corporativo (EJB):
Interface para fachada do módulo da aplicação > [implementado por] >> Session Bean que disponibiliza os prncipais métodos para o módulo > [utiliza] >> Classes de Negócio (Sessionbeans EJB) >>> utiliza >>> Interface de gerenciamento de persistência >> [implementado por] >> Session Bean que utiliza o EntityManager >>>[manipula] >>> Entidades (JavaBeans)
Módulo Web - interface gráfica:
Páginas XHTML >>> [acessam] >>> JSF Managed Beans >>> [acessam] >>> Interface para fachada do módulo da aplicação
Então, como se pode ver, MVC não é separar a aplicação em tres pacotes (model, controller e view) e jogar tudo de qualquer jeito lá dentro. Mas sim, a forma como você organiza a responsabilidade dos seus componentes, independentemente dos pacotes em que eles estejam.
