A few of our guys who went on the JP Boodhoo's "Nothin' But .NET" course came back with the same opinion. Managing bigger teams, with developers of all abilities is a different problem space entirely tho. Running NDepend with CQL queries in your build can allow you to add some rigour and stop people introducing silly dependencies. Otherwise you're down to trusting that people will (and know how) to do the right thing.
One thing about multiple assemblies I do like (and has saved me in the past) is being able to patch a production environment by dropping in a single assembly and modifying the bindingRedirect settings.
As for your second point - we have ILMerge in the Build & Deployment Process for that very reason! The lovely thing about the Fluent Registration in Windsor is that you can merge assemblies and not have to worry about the mapping files / references. Bliss!
Lots of the projects within the "Framework" folder are generally removed and introduced as libs after the first couple of sprints once the churn has calmed down a bit. The downside to having a large number of projects is the "CopyLocal = true" tax which can kill performance (see
Patrick's analysis of this phenomena) - I'd much rather have all project building to a common folder. This would also solve the problem of having to include all references (or having a post build script to copy assemblies) into your "presentation" project so that your DI framework can resolve dependencies.
Part of the purpose of the structure, is to get people thinking about *what* they're developing and *where* it actually belongs. If you have all your code in an amorphous project - that can be a bit of a danger.
Interestingly - we don't separate out our tests into a separate project (except for maybe integration tests); we're doing BDD - we generally have a 1:1 pairing of Class to Spec, i.e. ProductController and ProductControllerSpec living side by side. It makes it very visually apparent when a class doesn't have any test coverage. If you want to be very OCD about it (I generally am) you can use the VSCommands 1.0 addin to "group" the two files together, so the Spec appears as a code-behind to the Class it's testing. Having Class and Spec living side by side means you can also create R# live templates to generate stubs for both classes then you can use R# to move them into different physical files.
/Howard