1. The author is mistaken about being unable to run different applications with different security policies in .NET. The Java and .NET designers took different approaches here:
* In Java you have a variety of security policy files and specify which one to use as you start the application.
* In .NET you have a single security policy file at each level (Enterprise, Machine, User) which gives the general rules and the exceptions on a per-application basis. So for example you can specify that this application can access certain files but other applications can't. The security configuration files can be easily be shared among machines to keep a consistent security model across the enterprise.
The main difference here is that in Java the actual security you get depends on the command line you use to start an application. In .NET the security is unaffected by the command line, making it easier to be sure you're getting the security level you require.
2. The reason Java needs to preserve the bytecode stack for runtime checks is due to a flaw in the design of the JVM which renders it difficult to verify without doing so. The designers of .NET learned from the Java's problems and defined IL in a slightly different way that makes it unnecessary to incur the extra overhead of an extra runtime stack.