アノテーションが嫌われる理由

アノテーションが嫌われる理由を読んで、興味深そうな話だけれど、あまりピンと来ませんでした。
「アノテーションをつけたらPOJOじゃない」というのは、「もしも『アノテーションをつけなければいけない』としたら、それは『特定のインタフェースをimplementsしなければいけない』とか、『特定のクラスをextendsしなければいけない』というのと大して変わらない」というほどの意味なのですよね。
つまり、アノテーションは、一種の言語拡張機能によってyet another色づけをしているだけである、と。
何か私が勘違いしているんでしょうか。
（2005-07-28追記）id:nowokayさんから、以下のようなコメントをいただきました。

アノテーションはextends/implementsのように「オブジェクト指向」的には影響を与えないという意味でPOJOなのかなと。そのアノテーションを気にしない限り、ほかのコードには影響を与えませんよね。

ふむふむ、理解しました。そうすると今度はPOJOって何だろう。何のためにPOJOなんだろうということを考えたくなりますね。
（以下、思いつくまま書いているのでいいかげんです。それから上記の「アノテーションが嫌われる理由」ともポイントがずれた話です）クラスを組み込むために、ぎちぎちの制約(extends/implements)が必要になるようなフレームワークより、リフレクションAPIとかDIなどを使って効果的にPOJOを組み込めるフレームワークが注目されている。というのが最近の流行だと思っています。さらにアノテーションをうまく使うと、POJOでありながら、軽い制約をかけた形でクラスを組み込めるフレームワークが作れる。…と書きつつ疑問が生まれる。本当だろうか？　アノテーションをつけてクラスやメソッドにマークをつけるという行為はやっぱりPOJOじゃないように思うなあ。オブジェクト指向的にどうかというよりも、再利用的に。マークをつけたクラスを他のフレームワークに持っていこうと思ったとき、そっちのフレームワークでは同じアノテーションを別の意味で使っていたら困るから。あ、でもこれはアノテーションのネームスペースの話か。ドメインなどでプロジェクトごとに固有のアノテーションを作れば問題はないか。でも、フレームワークに組み込むためにアノテーションをつけなければならないとしたら、それはやっぱり再利用性を阻害しているように思う。アノテーションが単なるヒント情報ならば理解できるけれど、そうすると今度はアノテーションをつけることのメリットが失われてしまうし。…思いつくまま書くとわけがわからんな。でもいいや、送信。