Is everything under the GAC precompiled (ngened)? If so, then all of .NET is precompiled, so it's not possible for the CLR to optimize them at runtime?
Like if you use List in your application then CLR will not be able to optimize the List itself, but only how it's used in your app? Doesn't this defeat the purpose of JIT, to get lots of optimizations at runtime? So effectively losing all the potential optimizations for the BCL?
No, the GAC is not automatically pre-JITted; however, GAC is a pre-requisite to pre-JIT. Actually, only a small minority of things are pre-JITted. Besides which - if the BCL was pre-JITted, then those optimisations would have already been done by NGEN, so the " losing all the potential optimizations" is a non-issue.
No, the global assembly cache is not precompiled.
Newer versions of the framework do have an optimization service running in the background that does some precompilation. But as it runs on the target system all the precompilation it does is optimized for that specific system.
If an assembly is loaded from the GAC the strong-name verification is skipped because the assembly has already been verified. Another advantage of the GAC is file protection (admin-only).
NGEN has its own storage for native images. It makes a little sense to use NGEN without putting an assembly in the GAC first. In such a case loading the assembly would cause to verify its SN signature, which means that the cryptographic hash is recreated each time the assembly is loaded.
The best practice when using ngen is to put assemblies in the GAC as well.
The GAC can contain non-ngen'd code (it must contain it as well as the native images when using ngen since ngened images do not contain all the needed meta data). Ngen'd code requires the dll be installed in the GAC to function efficiently (technically you can do it without but the resulting name verification triggers full read of your dll anyway which is likely to make your startup time worse).
Pre 3.5 sp1 the ngen compilation was definitely fractionally different from the runtime one see this article for some more details. I would imagine this still holds true for 3.5SP1 since those issues are hard to solve.
Since ngen only really gives you two big wins you should consider whether either/both are significant in your scenario to justify the complexity and cost associated with their use.
I suggest This article detailing some of the changes in the 2.0 ngen is a good read, it covers things like hard binding which is a big improvement and links in to the excellent general documentation on writing efficient managed code though it has suffered from link rot see msdn Chapter 5 it refers to. (note that that doc is old but many of the themes are still valid)