知識が古いと困っちゃうのはリーダーより上の人

正直なところ、コーダーな人に対して「XXができないなんて!」ってプロジェクトはレベル高いというか、手段と目的を取り違えてなければいいけど、と思わなくもないですが、もちろん、そういうところも必要です。
業務プログラマーとして必要なJavaの知識なんてそれほどでもなくて、どっちかというと頭の良し悪しの方がよっぽど大事なんですが、まあそれはおいとくとしても、例えば継承とかインターフェースの概念がわからなくてコピペして動くからいいでしょとかそれどうやって呼び出すんだよコラな人は問題ですね。

特に、Java 5以降の機能
・拡張for構文
Enum
・可変長引数
辺りを全く知らなかったり。

経験年数2年半のJavaプログラマがちょっと書くよ。

使うんなら知っていてくれたほうがありがたいけど、そんなに使うもの?それから、知らなきゃ使えないもの?

って言うか、Javaの極々基本的な知識である
・equals/hashCodeの実装
・Serializableの実装
Iteratorの実装
が全く出来ないんだよね…。

経験年数2年半のJavaプログラマがちょっと書くよ。

そんなに基本知識でもないような…equalsを駆使しなきゃならないような業務プログラムってそんなにあるかなあ。Serializableなんてフレームワークがかっちりしていれば個々のコーダーが使うことなんてほとんどなさそうだし、Iteratorは確かにわかんなかったら困るけど、これもどっちかというと仕組みの範疇で、リーダークラスがちゃんとしてればよいんじゃないかな。
それよりも、問題は古くからJavaやってた人はJavaの知識が低くて、それがリーダーとかPMになってるプロジェクトで「あれは遅いから使うな」とか、「コーディング規約はこれ!(JDK1.4.2時代のもの」とか。そういう方が困るんですよね。ぶっちゃけ、知らないだけなら覚えれば使える。でも、実践を基にしたテクニックは消去するのが難しいのですよ。
遅かったことのJavaチューニング技法なんて最後はJavaの特性なんか知るか!的な手法にまでなっていたから、パフォーマンスで苦しんだ経験のあるPMなんかは頑なにリフレクションを拒んだりして。まあ、使いすぎはよくないんだけど、全く使うなとかね。
あと、出始めた当初に業務で使っていた人って基本的に「プログラマー」なんですよね。JavaってVMに対するハードウェア的理解なんかもあったほうがよくて、JITによる最適化とか、メモリ(パラメータ)チューニングによる性能改善なんかが結構見込めるのだけれど、そういうの無視。コードが遅いから遅いんだ!みたいな。GCの性能も上がっているのにやたら回収させるための無駄コード書かせたりとか。そういう人がいるとプログラマーが立派でもダメだよね。
新しい技術なんてちゃんと出来る人ならちょちょいのちょいで覚えられるんだから、もう少し本質的なところを見たほうが良いと思うんだよな。業務プログラマーなのに自分が何の仕事しているのかわからなくてもいいって人がいっぱい居るほうが問題なんだよね。過去の開発経験なんかではそのへんを聞くとものすごくしどろもどろな人がいるんだよね、結構。