そもそもの出発点として、従来のとりあえずログを取ればよい、というところから、今後は内部統制、すなわちリスクコントールと置き換えて考えると分かりやすいのですが、そこで要求される範囲・対象として、存在するリスクの評価し、それにあわせたコントロールにのっとってログを取得する、という方向にシフトしなければなりません。
つまり、データベースに起因する、あるいはデータベース層のみで捕捉できる事象については、データベース層での必須の対策として、また、アプリケーションやネットワークでの各種制御機能が100%ではないため、それを補完する機能、または最終的に担保する機能を担うデータベース層での対策として、データベース監査を考えれば間違いはないと思います。
具体的なリスクについては、個々の事情に依存する部分も多いのですが、以下のようなリスクについてはほぼ汎用に適応できると考えられます。

• sysdba等、特権ユーザーの操作(特にネットワークを経由しない直接の操作)
• データベースユーザーの権限管理
• データベース上で稼動するプログラム(パッケージ、プロシージャ)の管理
• アプリケーション/ネットワーク層でのフィルターやコントロールをすり抜けてしまう不正行為 (SQLインジェクションなど)

無論、データベースへの接続ユーザーを共通にしていることで実際のユーザー特定が困難であるとか、データベースの設定がデフォルトであったり、パッチ適用やバージョンアップをしていなかったりすることによる既知の脆弱性が存在するなど、基本的なリスク軽減も必須です。データベース監査がすべてではなく、リスクを評価した上で、必要な対策としてデータベース操作ログが存在することを理解していただければと思います。