Upgrade procedure should use only SQL and not PHP functions

The upgrade procedure is a real nightmare. One major issue is that since the upgrade procedure calls PHP functions, which change from version to version, it is likely to break if you attempt to upgrade more than one version at a time. Take this example:

CRM/Upgrade/TwoTwo/Form/Step3.php line 154

require_once 'CRM/Core/OptionValue.php';
$optionValues = array( );
$grpParams['name'] = 'from_email_address';
CRM_Core_OptionValue::getValues( $grpParams, $optionValues );

This results in an error when run because the PHP is expecting a different schema on the civicrm_option_value table.

Upgrading through each individual version is not realistic for sites that have a development->staging->production deployment strategy. Especially when there is extensive integration between CiviCRM and other applications that all needs to go through rigorous quality assurance checking for each deployment. And a production site that must keep downtime to a minimum.

Right now I'm trying to decide whether to rewrite these in SQL as I encounter them, or do some sort of multi-stage deployment when I upgrade to a particular SVN revision, run the CiviCRM update, update to the next revision, run the CiviCRM update, etc. However that method will block anyone else from doing any development on any other part of the site while I get this all arranged and deployed (and I don't see how branching would help).

The alternative is to just stay at 2.1 for the foreseeable future. But that prevents me from contributing to CiviCRM development. I'm guessing that this might be the option that the client chooses.