1. Because it's extra work, and a source of potential errors. If you don't have to deploy, there is no possibility of error in the deployment process. Deployment can be expensive if you have to take down one or more servers to do it.

2. Anything that changes a DLL will cause a rebuild and redeploy. Specifically, if you make a change to the DLL's code, you will need to rebuild and redeploy it (assuming the change is a significant and desirable one).

3. Some languages like Erlang have "hot deploy" capabilities, which means that you don't have to take down the server or device to deploy changes. This is useful for things like phone switches and traffic lights which must be running 24x7.

4. See 2.

1. Because it's extra work, and a source of potential errors. If you don't have to deploy, there is no possibility of error in the deployment process. Deployment can be expensive if you have to take down one or more servers to do it.

2. Anything that changes a DLL will cause a rebuild and redeploy. Specifically, if you make a change to the DLL's code, you will need to rebuild and redeploy it (assuming the change is a significant and desirable one).

3. Some languages like Erlang have "hot deploy" capabilities, which means that you don't have to take down the server or device to deploy changes. This is useful for things like phone switches and traffic lights which must be running 24x7.

4. See 2.

Bad architecture, from Uncle Bob's point of view, means that the code is too tightly coupled. Code that is too tightly coupled causes increased rebuilds and deployments, because your code has too many dependencies on other code in other DLL's. Consequently, making changes to one DLL often cascades into changes required in other DLL's.