The main situations where I have encountered Java applets for authentication purposes are signatures. Consider that the server or the client could be an attacker; typically, an online banking/stock exchange site. The user can send buy and sell orders, and may later on try to default on his orders by claiming that he never sent them in the first place, and that the bank is trying to frame him. At that point, the customer and the bank go to see a judge.
In a typical password-over-SSL authentication, on the technical side of things, the bank loses. Indeed, the bank can be reasonably certain that the customer indeed came and sent the orders; but it cannot prove it. For a proof, a digital signature is needed: the customer signs the order, with a private key that the bank knows not. A client certificate for SSL is not sufficient, because the client signature is then upon the SSL session elements, not the application data.
.jar files will be cached on the client's machine, are signed (so the bank cannot repudiate them), and could be reverse-engineered (this is not that hard for Java bytecode).
Note that, similarly, the applet signature protects the customer, since any felony from the bank itself could be uncovered that way; the signature makes frauds more risky, thus (presumably) less probable.
I am not claiming that this is what your specific example of Java applet does, but at least it is a scenario where Java applets have benefits for security.