Why should I NOT use the GAC?
If you have a small application that is not that resource intensive, then I wouldn't want to install files into the GAC.
It would create another dependency that I would need to check for in my uninstall and there has been a lot of grief expressed in the past about programs that abuse the registry.
It would also be a little easier for debugging/maintenance in that you could easily verify that all the appropriate libraries are in the executable path of the application.
If you want a less intrusive deployment of your application. By only installing in your application directory you can copy deploy and clean up very easily.
We have an application that has 50+ .NET assemblies loaded at any given time and we do not use the GAC. I think the GAC is most useful if you have to have multiple versions of your application running at one time, each of which needs to load a different version of the same shared library.
Even then, if the two application versions are in different directories then as long as you keep their binaries separate you still don't need the GAC.
I've always felt it is far more useful for someone that makes an SDK/API, where different versions of their SDK can be loaded by multiple applications and live in harmony. So if you are in this boat then the GAC may make sense.
There are some fringe cases that require the GAC (I think .NET COM+ components need to be in the GAC in some cases), but I think those are a small percentage of the cases.
Chris Sells gives probably the best reason for avoiding the GAC where you can:
What this boils down to is that any of the shared spots for updates, whether it's a COM CLSID, windows\system32 or the GAC, are dangerous and should be avoided. And this is why the preferred .NET deployment scenario is "xcopy deployment," i.e. having your own private copy of each DLL that you test and deploy with the rest of your application.
"Aha!" you say. "The GAC supports multiple version of an assembly! When a foo.dll is updated to v1.1, v1.0 sits right along side of it so that your app doesn't break!" Of course, that's absolutely true. But if that's the case, why do you care? I mean, if there's a new assembly available but your app isn't picking it up, what difference does it make?
"Aha again!, you say. "I can put a publisher policy into the GAC along with my assembly so that apps are updated automatically!" That's true, too, but now, like any of the machine-wide code replacement strategies of old, you're on the hook for an awesome responsibility: making sure that as close to 0% of apps, known to you or not, don't break. This is an awesome responsibility and one that takes MS hundreds of man-years at each new release of the .NET Framework. And even with those hundreds of man-years of testing, we still don't always get it right. If this is a testing responsibility that you're willing to live with, I admire you. Personally, I don't have the moral fortitude to shoulder this burden.