You didn't get the point. It doesn't mean you should put ALL the config information into SQL, but the parts, that define classes within assemblies that should be dynamicly loaded like state management class etc... It gives many suggestions. You should use AT LEAST ONE of them.

Excerpt:

Threat: Malicious assemblies are loaded during runtime
Threat target
 An application that uses the UIP Application Block
Risk
 Because UIP relies heavily on the configuration file, the configuration file can be used as a break-in point for hackers. UIP uses the configuration information to dynamically load assemblies. Additionally, critical information, such as the SQL Server connection string, is stored in the configuration file. This information is at risk because it is in plain text format.
Attack techniques
 The attacker deploys malicious assemblies on the client and alters the configuration file to force UIP to load the malicious assemblies. The attacker can then take control of the workflow.
Countermeasures
Use the Configuration Management Application Block (CMAB) to increase the level of protection for the configuration file needs.
Specify another resource, such as the SQL Server computer, to provide the configuration information, instead of the traditional ExecutableAssemblyName.exe.config.
Permit UIP to read Class information from the configuration file only, instead of from the entire assembly information. The drawback to this approach is that all assemblies must be known at compile time.
Declare all assemblies that are part of the application and use SecurityAction.FullDemand.