Because it gives the Java programmer too much power in an environment that should be safe. For example there are applets like AppEmbed that can run an EXE in the browser. That's just insane. Flash and Shockwave in contrast are limited in that sense, you are constrained to doing what you are able to accomplish with ActionScript or Lingo (or at least, that is intended to be the case.) Flash is insecure because it's buggy, Java is insecure because it's buggy AND because it's intended to work in ways you'd think are obviously insecure!
Applets, unless especially privileged by the user, run in a sandbox that prevent them from interacting with the local OS [1]. They certainly cannot run EXEs, again, unless the user consents.
In theory the Applet sandbox works really well. It's an extremely secure environment that's been deployed widely in the most demanding conditions -- think banks and governments. In practice the Applet security model encountered the following problems:
(1) Users are really, really dumb. They are happy to grant escalated privileges to the some 3D farming game they stumbled upon on the internet. Users will literally click on anything you tell them to. [2]
(2) Getting users to upgrade Java was terribly difficult. This meant when a real security flaw was discovered it might hang around for years and years and years. There was no mechanism to force users to upgrade Java or to actively disable Java installations proven insecure.
Maybe I'm confused because it's only relatively recently that I started again to take Java seriously, but isn't that precisely an example of a domain the Java security manager addresses? Again, I am well aware of the implementation bugs that have existed, and I don't know offhand if the security manager was part of Java's initial design or was added later, but I'm still confused as to why your ire's directed at the general concept of Java in the browser, rather than the specifically flawed implementations.
There's just no safe way to do what Java applets enabled (arbitrary code execution), because of the massive attack surface. It's one reason why NPAPI is dead.
Java applets never enabled arbitrary code execution. (Where do people even come up with this stuff?) Spend five minutes on Google and you can learn about the Applet sandbox which prevented Applets from doing most anything but draw to a section of the browser window and connect back to their origin server (not unlike Javascript).
Yeah, what do you think the applet is run on? The JVM. That's the attack surface. And securing that went so well that everybody uses Java applets everywhere and applets are allowed by default (hint: securing it is impossible and they're disabled by default because of it).
