In WF 3.5 custom activity input was written to properties. The developer who would use these activities would set values to properties directly in the designer or using binding.
In WF 4.0 it is possible continue to use regular CLR properties or to use Input Arguments exposed as properties.
The question is when to do what.
1. When the input value is needed before the activity is executed, for example in the CacheMetadata method – CLR properties are your only option. Input Arguments are visible only with a context object provided in the Execute method. I had a project where I wanted to create arguments on the fly using information supplied by the WF developer. This could only be achieved using CLR properties as dynamic arguments are created in CacheMetadata.
2. If the value needs to be persisted it must be contained in an Argument because the activity's CLR properties are NOT persisted. (It is always possible to use a persistence participant to solve this problem)
3. CLR properties cannot be set in the designer property pane with an expression. Only simple kind of types can be set (for example: System.Type)
I hope these considerations will help …