1) A Code Activity places method stubs into the same class as the work flow (The work flow designer works in a similar way to the Windows Forms designer. If you click 'Show all files' on your project you can see the work flows auto-generated designer class) .
CallExternalMethod calls a method that exists in another class. So you don't need to put all your logic in the same class as the work flow, you can spread it across other classes like you would normally.
2) I guess if it's a significant part of your applications behaviour it's nice to see it on the work flow (so you can get a good visual overview of what's going on). Also, with the Work flow delay activity your work flow gets marked as Idle. So if you are using a Persistence service you're work flow gets automcaticllay persisted at this point. There's also the WorkFlow OnIdle event that you could pick up from outside the work flow. I dont know if this applies to delays via code.
3) Not sure that I correctly understand this one. If you're passing something into a work flow you are going to need a property / field to bind it to, but the type definition does not have to be in the same class/ assembly. So long as the project the work flow lives in can reference the one you're Enum lives in, you should be fine.
Click your if else branch, select properties. Click the Condition box, change it to * Declarative Rule Condition*. Give your condition a name, in the Expression box enter your If statement like you would normally in code.