Fewer smaller .Net DLLs vs less large DLLs

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 resources