That is only for a specific purpose, not general deployment of JARs.
For the full story, see "How Classes are Found"
There are three class paths, for the bootstrap classes, extension classes and
user classes, in that order.
The bootstrap classes are the actual Java platform. The extension classes are
adaptations of the Java node itself, platform-level functionality. The user
classes are those in the application classpaths.
Putting JARs in the extension directory(ies) is analogous to putting DLLs in
the Windows system directory(ies). They become part of the system, in this
case, something like becoming part of the Java language itself. Occasionally
this is what you want, but it harms portability, is inescapable for other
applications if not all apps want those libs, and is usually not necessary.
I've seen issues in practice when an environment lacked extensions that were
assumed by the code, say, those for a non-Sun JVM. Extensions suit well,
OTOH, for JARs that adapt the host environment to look more like a typical
Java host, a conceivable use case, or for focused-purpose nodes where the JVM
is tailored for specific features and not general use.
For general work and to gain maximum ease of deployment, packaging libraries
with the application is usually optimal.