I have seen a number of posts regarding implementing overrides for triggers, workflow and validation rules using custom settings/labels.
In practice / large complex Salesforce deployments are people actually implementing such a thing?
There are definitely use cases for it, and it doesn't necessarily hurt the system to have a check in place.
For instance, say you are building a recruiting app. This app was originally built on a different system and contains legacy data. This app has a before insert trigger on the custom object Interview__c which enforces that the custom date/time field Interview_Date__c has to be in the future. Now, in order to get the legacy data into the system properly, you would have to deploy the objects before the trigger, load the data, and then deploy the trigger. Now fast forward this by 6 months after the deployment. A part of the company was never moved onto the new Salesforce recruiting app when it was deployed and continued using the old system. You now have 6 months worth of data that you need to import. The easiest way to do that would be to set a custom setting value and have your trigger reference it. If the custom setting value is false, it skips the validation, otherwise it runs. You can now lock down the system overnight, switch your flag, and simply load the data. There are no code changes involved and it makes the introduction of new legacy data much simpler.
Now, that was only a single simple example, there are a multitude of others but this was the first one that popped into my head. If you would like me to try to think of more I can do that, but my main point is although it seems counterintuitive, adding something to override your triggers/validation rules/workflow isn't always a bad thing and at times can be very useful.
For an enterprise customer I work with, we have added a custom checkbox field on the User object, named "Validation disabled".
Next - for every relevant workflow rule, validation rule, and trigger across our instance, we have included a conditional filter to exclude User.Validation_disabled__c=True - so for instance - for system-to-system usernames we have checked this as True, so that when any updates are made by this user, these transactions will bypass workflows/validations/triggers and not result in errors.