It is a very important option, blindly applying it is not a good idea.
COM has a very strong DLL Hell problem. Registration of a COM server has machine scope by default, caused by the server registration written to the registry in the HKLM registry hive. Very Bad Things happen when you change the implementation of the server and a client program that used the server is not recompiled and upgraded on the machine. Keep in mind that you can only directly control the version of your server, there's usually very little you can do about making sure that the client program is updated as well.
The good kind of very bad thing that happens is when you follow the COM contract and give the coclass and interfaces a different {guid}. The client program will not be able to locate the proper interface anymore and fails at runtime with the REGDB_E_CLASSNOTREG or E_NOINTERFACE runtime errors. The user can usually figure out what went wrong, doesn't exactly make him very happy about it of course but some odds he'll take his own corrective measure and delete your update.
The very bad kind of very bad thing that can happen is that the COM client doesn't fail locating the coclass and interface but the call fails. Could be the completely wrong function, could be that the arguments are no longer compatible. That kind of failure is utterly undiagnosable, the user has no hope to figure out what went wrong. You'll get a "It doesn't work, help me!" phone call.
.NET has very strong support for allowing different versions of an assembly to live side-by-side on a machine. The GAC is where they are stored, the [AssemblyVersion] attribute is the key. So a client program that's recompiled to use the new version will automatically use the new version of the COM server. A program that wasn't recompiled will continue to operate correctly with the legacy version of the server. The GAC provides the version they need.
The GAC can be useful for a .NET class library as well but not nearly as important since most .NET libraries are deployed locally, in the same directory as the EXE that uses them. Not the case for a [ComVisible] .NET library since its registration is machine-global. There are counter-measures against that by using a manifest but this is up to the client program, not the server. Again outside of your control. And often very impractical if the client program is a widely-used program like an Office app or Internet Explorer.
So deploying your COM server to the GAC is very important, you really want to take advantage of the DLL Hell counter-measures and have some confidence that updating the server doesn't cause massive problems.
The only time you want to use /codebase is when you are developing and testing the server. In which case you of course never worry about DLL Hell, you always use the latest version and don't want to be hassled by the need to put it in the GAC. Easy to forget, that's an hour of your life you'll never get back.
