This isn't a case of my-language-can-beat-up-your-language syndrome. JPython doesn't replace Java; it augments it. Java and JPython have complementary roles - sometimes they overlap.
JPython facilitates the following:
Embedded scripting language: You can add JPython to your application to enable those pesky, demanding end users to extend your applications through scripts. Thus your end users can extend your application to add functionality that only a domain expert could dream of.
Interactive experimentation: JPython, like many scripting languages, provides an interactive interpreter. I use this to try out new APIs and for prototyping. Also, this is a great debugging tool - you can execute methods in any order, not in the normal sequence. Since the syntax is close to Java, it's easy to prototype.
Rapid application development: Python programs are shorter than the equivalent Java programs, as I'll show in the Rosetta stone examples.
Python is a lot easier to learn than Java. A novice programmer can learn enough Python in half a day (or sometimes in a few hours) to write effective scripts. In addition to being good for programming-in-the-small, you can use it for larger programs. Python has advance namespace management that makes programming-in-the-large feasible - many scripting languages don't. For example, Python has packages similar to Java's.
Back before Java became popular, I was a C++ bigot. I programmed in nothing but C++. I lived, ate and breathed C++. If it wasn't C++, it was rubbish. I thought C++ was the alpha and omega of object-oriented programming. I had "operator overloading" for breakfast, "templates" for lunch and "multiple inheritance" for dinner, and I always went back for seconds.
Then a funny thing happened. I got a new job at another company as a C++ programmer. But they pulled the old bait and switch. Once I started working, someone suggested writing a good portion of a large project in a scripting language. I protested - I would not condescend to program in any other language but C++.
Shortly after I started at this new company the following edict was put forth: "Thou shall use a scripting language." Thus I was forced by management to write a good portion of the project in a high-level scripting language. They told us to glue components written in C++ together with this scripting language (in addition to writing components in C++). At first I hated it, as any self-respecting C++ bigot would. Then, gradually, the productivity of my team - and me - skyrocketed.
I became a true believer in scripting languages. The more I saw productivity climb, the less I coded in C++ and the more I coded in the scripting language. Granted, the scripting language had some limitations, but for many tasks it was just what the doctor ordered. Have you had a similar experience with a scripting language? If not, perhaps you should.
Many scripting languages are either object-oriented or object-based. Almost all of them are interpreted and use late-bound polymorphism. This makes scripting languages extremely dynamic and easy to program, which is essential for rapid application development (RAD), gluing components together and prototyping projects.
There's a fine line between a scripting language and a programming language. For example, Smalltalk is an extremely dynamic interpreted language, yet I dare you to call it a scripting language to a Smalltalk evangelist - you'll probably get punched in the nose. When I refer to scripting languages, I'm referring essentially to languages that are mostly interpreted and extremely dynamic, that is, they employ late-bound polymorphism and dynamic typing.