AOP(ライブラリによるProxy生成型)が不要だと考える理由を書いてみます。

AOPの用途

AOPの用途といった場合、以下のようなものが挙げられると思います。

以下、それぞれのケースに対して、なぜAOPが不要だと考えるのかを記述します。

一般的にAOPの利用を想定するケース

アプリケーションのログとは定型なパターンで出力するものではなく、アプリケーションの意味ある単位で固有の情報(例えばログインに成功/失敗した等)を出力するものです。
AOPによる定型的な出力では、出力タイミングと出力する情報の観点でこのニーズに対応できません。

なお、ログではなくメトリクスについては後述します。

トランザクション制御をAOPで行う場合、メソッド単位でのトランザクションスコープの制御になります。
単純なケースではこれでも問題ないかもしれませんが、処理順序やスコープの範囲に工夫が必要なケースではこれでは融通が利きません。

リソースのスコープ管理は、Loanパターン等で明示的に行う方が融通が利きます。

記述の簡略化という観点では、メソッドにAOP用の属性を定義するのと比較して、ヘルパーや言語のイディオムを使ったLoanパターン等の記述が面倒と言うほどのことはありません。
それよりもリソース管理のスコープ制御に融通が利く方がよほどメリットがあります。

こういった処理はAOPを使って行うようなものではありません。
本当に妥当な前後処理であれば、それはランタイムのグローバルハンドラを使ったり、フレームワークのフィルタ機構や拡張ポイントを使って行うべきものです。

昔のフレームワークでは拡張ポイントが不十分でAOPにより無理矢理拡張ポイントを作ってこれらの処理を行っていたケースもありますが、今のフレームワークが対応していないとしたら、それのフレームワークが(検閲削除)なだけです。

RESTクライアントやDataAccessor等、interfaceのコントラクトから実装を生成するタイプのライブラリがあります。
これらについてもAOPに含めて話をする場合がありますが、それらはAOPとは別物として扱うべきだと考えます。

「ログ」ではなく「メトリクス」の出力については、唯一AOPの使用が妥当だと考え得るケースになります。

「ログ」はアプリケーションの意味ある単位で意味のある情報を出力するため非定型なものですが、「メトリクス」については定型的に出力した情報の集計結果から意味を見いだすものなので、AOPによる定型的な出力という対応が妥当な判断となりえます。

っというわけで「基本的にAOPは不要」っというのがワイの考えじゃ( ˙ω˙)