Say you have the same code (Production) running on different servers - for example, a local instance on a developers own machine, a test server used for system testing and a production server.
Your code accesses an external web-service. The actual web-service will be different for each system - maybe a mock service for the developer, a test version of the web-service for the test system and a production version for your production server. Then the URL for accessing the web-service would be different for each one.
In your code you have a setting on the business operation in your production that connects to the web-service. The value of this setting can be set from the System Defaults Settings page, and will contain different values between the servers.
This allows you to separate out settings that will be the same across all servers, and settings that will differ between servers - settings that are the same on all servers can be set on the services/processes/operations themselves, settings that differ will be set via system defaults.
Not sure it counts as an answer, but what we did to step round this issue was to move the bulk of the functionality - where the error handling was required - into a new business process, leaving only the most basic "pass the trigger message along" functionality in the business service. Added an extra component to the production, but we can now see errors in the log when they occur, and they are passed appropriately to Ens.Alert.
7 years after it was written, this comment helped us sort our problem - we are disabling components to prevent further attempts at processing on certain error conditions, and were struggling to get the EnableConfigItem() call to take effect immediately... Sorted now.