chris@vendiadvertising.com on "Extending WP_Customize_Control in plugin throws errors"

I've created some additional types of customization controls for a theme using Otto's tutorial. I'd like to now package these into a plugin to share code across several sites. Using Otto's exact syntax in a plugin, however, throws a fatal error: Fatal error: Class 'WP_Customize_Control' not found...

<?php
/*
Plugin Name: WP_Customize_Control Error
Description: This plugin causes "Fatal error: Class 'WP_Customize_Control'" to be thrown
Author: Chris Haas
Version: 1.0
*/

class Example_Customize_Textarea_Control extends WP_Customize_Control
{
    public $type = 'textarea';

    public function render_content() {
        ?>
        <label>
        <span class="customize-control-title"><?php echo esc_html( $this->label ); ?></span>
        <textarea rows="5" style="width:100%;" <?php $this->link(); ?>><?php echo esc_textarea( $this->value() ); ?></textarea>
        </label>
        <?php
    }
}

The simple solution would normally be to just include that core class using the below before the declaration:

require_once( ABSPATH . WPINC . '/class-wp-customize-control.php' );

This gets rid of the error until you go into Appearance->Customize where you get a different error, Fatal error: Cannot redeclare class WP_Customize_Color_Control in ... /wp-includes/class-wp-customize-control.php.

Ultimately this stems from wp-includes/class-wp-customize-manager.php line 70 (as of 3.9.1) where the file is loaded using require instead of require_once.

I found someone performing an on-demand load of their class in customize_register but that requires the theme to be aware of my plugin's file structure which isn't ideal.

Am I missing something obvious? Is there a good reason that that core file is loaded using require instead of require_once? As far as I can tell its a static class that could probably be loaded at almost anytime.