You can allow an end user to pick his own jdbc driver for instance. And if the classes are not found in the library the end user picked, you can tell the end user the library was improper. With existing classloaders, they will just start checking the system classloader for the classes. You may not want the system classloader checked.
If you want to load a new version of a class when it is available, without having to stop and restart the JVM, a class-loader is essential. (I am not sure what "Custom" means in the original question.)
You'd use them whenever you need classes loaded in a different way than the standard classloader provides. Examples might be classes that are not in the classpath, classes that are encrypted on the disk, classes that are loaded from a database or over the network, or classes that are generated from source code.
Interesting article. But it supposes that unencrypted classes are available, which is the case only if the password has been entered (because otherwise no attempts would be made to unencrypt the classes). A determined attacker would buy a license, get a key, and be able to access the bytecode. For against a casual attacker -who might do this in order to avoid paying license fees- the scheme does add additional security. But as you point out, obfuscation should definitely be used as well. [ June 11, 2006: Message edited by: Ulf Dittmer ]