To sign an assembly A you have to make sure all assemblies B, C, D that are used by A are signed, and then all assemblies that are used by B, C, D, and so on. I don't understand what's the security benefit of this. I think it's supposed to prevent tampering, but assembly A is allowed to open any file, and these can be tampered. The same goes for an external webserver.
Also, it's too easy to sign an assembly with a .snk file that you make public, sidestepping the requirement.
Another reason for strong naming is versioning. If you reference a strong named assembly, you get that specific version - and it will load its dependencies at the specific versions it relies upon.
EDIT
Example scenario: If you put an assembly in the GAC, it has to be strong named to allow side-by-side versioning. You couldn't put it in the GAC, though, unless its dependencies were also there (otherwise, they'd fail to load at run time). In order for those assemblies to be loaded reliably, they need to be strong named too, and in the GAC.
It's because the a strongly named assembly implies that it can be trusted, and levels of granted security are based on the idea that the code is from a legitimate source. This means that all other items that it interacts with must also be trusted, because it executes under the same security context.
If strongly named objects didn't work this way, a method of attack would be to replace the items which aren't signed with rogue code the attacker wants to execute. The rogue code would execute under the trusted security context of the signed item.
The point is that otherwise you could replace assembly B/C/D with a different (hacked) one, and A would never notice; it would load them and execute the code. With strong naming, you can't do this without either re-signing the hacked B/C/D with the same key, or by hacking A.