It depends why you are using the views.
1) If you are planning to use Edition Based Redfinition, then you never directly access a table. Instead, all code access the editioning view.http://www.oracle-base.com/articles/11g ... _11gR2.php
2) If you are using the view to hide certain columns from the developer, to make their life simpler.
3) If you are trying to define a simple structure (a single view) to the developer, which is actually fed from a complex structure (several tables). You can then use instead-of triggers to allow insert/update/delete of the views, which behind the scenes will update multiple tables.
4) Having the views in a separate schema that the developer has access to, without giving the developer access to the base tables.
All of these options have value in the right context, but just blanketly saying, I will create a view on top of every table for no particular reason is not a valid choice in my mind, especially if the developer can see both the view and the base table, because sometimes they may access the view and sometimes the table. This makes tracking dependencies trickier.