Oracleにおけるビューを含むSELECT文の実行計画の最適化には制限があります。
(他のRDBMSだと最適化はされるかもしれません。でもその度合いには限界があるはず...)
ビューを含むSELECT文の実行計画最適化における制限事項
ビューを含むSELECT文を書いたとき(SELECT文のFROM句にビューを含めたとき)
ビューで定義された問合せブロック（ビューで定義されたSELECT文）の内容を展開して、
SELECT文全体で実行計画を最適化する挙動（マージ）をオプティマイザーが示すこともありますが、これには以下の制限があります。
次の理由により、単純ビューのマージでは、ビューが有効にならない場合があります。
次のような、選択表示結合ビューに含まれていない構成メンバーがビューに含まれている。
・GROUP BY
・DISTINCT
・外部結合
・MODEL
・CONNECT BY
・集合演算子
・集計
・ビューがセミ結合またはアンチ結合の右側に表示される。
・ビューのSELECTリスト内に副問合せが含まれている。
・外側の問合せブロックにPL/SQLファンクションが含まれている。
・ビューが外部結合に含まれており、ビューをマージできるかどうかを判断する複数の追加の妥当性要件の1つを満たさない。
パフォーマンスのよいSQLを書くためには
つまり、上記の条件を含むビュー定義は実行計画の最適化が行われないということになりますので、
そのようなビュー定義をすることはパフォーマンスの面で不利がある、と認識してビューをつくる必要があります。
上記の制限事項を回避しようと思うと、単純に結合するようなSELECT文にしかできません。
そう考えるとビューをつくる意義があるのか？という結論に大概の場合に行き着くのではないかと思います。
（元々のビューの存在意義は、外部スキーマとしてユーザーのアクセス権限の制御（行と列を絞り込むため）、なのでそのように利用した方がよいということになります。）
マテリアライズド・ビューで対処しては？
とよく言われますが、リアルタイムで同期を取るには高速リフレッシュに設定しなければなりませんが、
高速リフレッシュの条件として上記制限事項が同じようにかかります。
また、完全リフレッシュをインターバルでするとなると、元のデータとのリアルタイムでの整合性はとれなくなりますし、インターバル間隔とデータ量によってはDB負荷がかなり増すのでお勧めできません。
結論
ビューで導出しなければならない属性があるのであれば、その属性をどこかのテーブルに追加して、
テーブル更新時のロジックにその導出するロジックを追加して更新するようにするのが、
機能面・非機能面(性能面)の両面で妥当かと思います。
補足
述語のプッシュ（ビューの外側で指定されたWHERE句の条件をビュー内に適用する）挙動もありますが、
※V_XXXXというVIEW、T_XXXというTABLEがあるとして。。。
１．SELECT * FROM V_XXXX AS V WHERE V.ID = 123
２．SELECT * FROM V_XXXX AS V,T_XXX AS T WHERE T.ID = 123 AND V.ID=T.ID
３．SELECT * FROM V_XXXX AS V,T_XXX AS T WHERE T.ID = 123 AND V.ID=T.PARENT_ID
１と２のように直接インデックスが効くようなキーに対して条件がリテラルで直接指定される場合（１）、または、直接指定される条件のカラムと結合されている場合（２）はプッシュされますが、
３のようにリテラルが指定されたカラムではないカラムと結合される場合にはプッシュはされません。
なので、述語のプッシュも制限がある（階層構造になっているようなデータは要注意）ので、ビューに対するアクセスでのパフォーマンスは期待しない前提で設計するのがよい、というのが基本です。
※Oracleのオプティマイザの仕様の詳細はこちら
OracleのSQL問合せ変換の仕様
http://docs.oracle.com/cd/E49329_01/server.121/b71277/tgsql_transform.htm#BABHJFGB