佐々木と申します。

　"エンタープライズ"の定義が良く分かりませんが、
設計上 stored procedure, view, trigger の使用が必須になるような
ケースは経験したことがありません。
4.1 で実装された prepare statement は性能に直結するので良い機能です。
システムの性能は仕様書に明記しないといけませんから、常に設計範囲内で
性能をコントロールできるかどうか、ここを一番重視して注目しています。

　開発者の立場から言えば、サポートも重要な点です。
例えば Oracle のサポートは実際に SQL を書いたり開発のアドバイスをしてくれます。
また、WEB上から他の利用者を含めた過去のサポート情報や技術文書を参照できる
のも便利ですね。
豊富な機能を売りにするのであれば、使いこなす為のサポート、
障害発生時のサポート、双方の充実が不可欠でしょう。

　それから、5.0 には関係ないですけど、ライセンスも大きなポイントです。
何年か前にシリコンディスク上で PostgreSQL をノンストップ稼動させる、
という開発を行いましたが、少しでも製品単価を落とそうと苦心する人間からすれば、
完全にフリーでないソフトウェアを使うのは実験といえども躊躇います。

　とはいえ、MyISAM が選択でき、Oracle のようにインデックスの
強制指定が出来る "軽い" MySQLには非常に惹かれるものがあります。
実際 4.0 は、開発や保守のし易さ、検索の速度など、私がこれまで
接してきたデータベースの中でも最高の部類です。
4.0 との互換性を含め、こういった利点を保つ続けるのであれば、
段階的に 5.0 の機能を試すことができて便利だと思います。