Actually if you are changing a dependency right at the bottom of the chain, it makes things much faster as each compilation unit (assembly) is less likely to be coupled to the changed code.
Large assemblies are the enemy of compilation time as you can't partially compile them (like you can with java individual classes).
Yes but that's not the case if you're changing a dependency in the middle of the chain, as is more commonly the case.
Additionally, as far as I can tell, the main thing that slows compilation down isn't so much the actual compilation step as loading in and copying all the project references. Visual Studio does this separately, from scratch, for every project that you rebuild, since each project compilation runs in a separate csc.exe process.
In that case it's probably sensible to break it up not only into separate projects but separate solutions too.
What bugs me is when relatively small solutions are broken up into large numbers of projects. Very often it's done for no reason whatsoever other than aesthetics. They're often divided up "against the grain" too, putting every layer of your application (presentation layer, business layer, repository, domain model, services, interfaces etc) into a separate project, with the result that a single task requires you to make changes to several different projects.
The general rule that should be followed here is the Common Closure Principle: classes that change together should be packaged together.
Large assemblies are the enemy of compilation time as you can't partially compile them (like you can with java individual classes).