Ainda que o banco fosse compeltamente relacional, como eu faço quando eu removo tabelas e não quero quebrar minhas aplicações existentes? O que eu faço quando decido que preciso migrar para uma versão mais nova do banco de dados e não posso atualizar as alicações que a usam hoje? Se sua resposta envolver mantêr views para o sistema legado eu não a considero válida. Isso é um sintoma de uma arquitetura que não deveria ser usada para integração, não possui contratos, não suporta mudanças e vai contra algumas décadas de pesquisa em interação de sistemas.

Ainda que um modelo relacional “de verdade” me ofereça possibilidade de não quebrar uma aplicação porque eu alterei meu schema -coisa que não faz- eu ainda teria que sentar e esperar alguem criar uma base de dados relacional “de verdade”.

Bases de dados não são o coração de nada, os dados em si é que são importantes. Como você os mantêm, se num SGBD relacional, OO, em arquivos texto ou o que quer que seja, depende da aplicação.

O que você fez foi colocar uma camada adicional, o que foi necessário porque os SGBDs SQL não são realmente relacionais, contendo entre outros problemas restrições arbitrárias sobre visões atualizadas que complicam a solução correta do problema; e não contendo todas as regras organizacionais como restrições de integridade declardas.

Mas as bases continuam sendo o coração.

No meu caso, é fazer a migração de um sistema Mainframe p/ um em Java, que será acessado via procedures, os old-timers aqui enchem a boca p/ falar que estão construindo um sistema cliente-servidor.

Só porque dá menos trabalho (se é que dá), não significa que uma solução seja mais simples. Fazer as coisas pior de propósito é uma lástima…