Generally speaking it is better to have less large DLLs versus many smaller DLLs for the following reasons:

• Hard Disk time:  Loading 100 dlls will almost always take longer than a single large DLL.   DLLs are physically scattered across the disk.  Latency etc come into play on the initial load times.
• Memory Usage: A single dll contains 1 set of "standard" meta data vs 100 times that standard meta data can start to make up some memory space (i.e. X bytes of product name, version info, etc x 100 dlls x # of app domains = memory)
• Security: .Net CLR has to do a lot more processing with multiple DLLs vs less DLLs.  A security policy will need to be loaded, managed, and executed per each DLL.
• CLR Management:  If DLLs do not specifically call for a unique "base address" so the CLR must re-base each DLL when it loads them costing startup cycle time.  Also when code executes the CLR must locate the object in memory and if it has to go through a "lookup table" of those addresses it will take longer to find one if multiple DLLs are used.
• Management: Locating code, determining DLL references to use, build scripts, etc will take more time to manage in the SDLC.
• Optimization: The .Net compiler can make more and better optimization decisions if acting on more code base.   Smaller sets of code will provide less optimization opportunities.
• Maintenance: Managing the additional project files, assembly info files, etc add time and understanding to developers.

Additional information: http://blogs.msdn.com/brada/archive/2004/05/05/126934.aspx