I'll give you one of many examples I have. Every morning a web based application I created and manage imports a large fixed length flat file from a legacy mainframe system. The mainframe app that generates this data is fed by people typing into un-validated form fields on terminals. My application needs to know about this data as soon as it shows up because it tracks a variety of metrics that are date sensitive. The data import routines clean up "nodes" as they come in externally and try to intelligently correct them for a variety of missing or incomplete elements. There is a level at which an imported "node" will be discarded because it just lacks too much information. The data is then inserted into the web app. For the most part this data would pass through the, now irrelevant, form validation routine. But not always, we let data in from the import that is missing elements that a user would be required to enter if they were typing data into the web app directly. We force users to enter this info, but can't force it from the mainframe. But, we can't throw this node out because we need to track it and know that the next day the missing info will most likely be included in the export file. In our application the data object are completely separate from the form elements, and in many cases we have multiple forms that talk to a data object with different validation rules.
to get rid of a given validation like taxonomy (for example), you just do unset($form[#validate][taxonomy_node_validate]). to get all of validators, use unset($form[#validate]). your custom cleanup routine could run outside of drupal framework on the file but it could run within drupal too. just add your own #validate handler and then process the form. thanks for the example. keep them coming! until we hear of a something significant that can't be done with the new system, i'm chalking up the complaints to unfamiliarity.