If you are building this for a single client, you should absolutely take advantage of mu-plugins.
There are a lot of things in WordPress that you can’t do in functions.php. Pluggable functions is one of them, but more obvious, a number of hooks (both actions and filters) fire before functions.php. In some cases, these hooks even fire before regular plugins, which then requires you to use mu-plugins or a network-activated plugin. In still other cases, even a mu-plugin is too late. Perhaps you need something in sunrise.php. Or even something (a constant or otherwise) in wp-config.php.
I would rather add some hooks to pluggable functions, than to make it easier to override them. We are not likely to ever again have another pluggable function — they pre-date hooks and I’ve almost never seen a situation where there is advantage to them over a good old-fashioned (new-fashioned?) hook.
I still agree, six years later, with Andy Skelton — “There are many differences between a theme’s functions file and a plugin. Let’s keep it that way.”
That all aside, a change like this could never happen. It would break a lot of things. Countless themes call functions in the body of functions.php that would result in a fatal error if pluggable.php hadn’t already loaded — like current_user_can(), or wp_create_nonce(). They’d all fail. And it’d break plugins, too, which normally could start calling these functions on plugins_loaded. (Just move pluggable.php lower in wp-settings.php and I bet half of core would break — or at the very least, the customizer would.)
Finally, there’s the inevitable idea that a theme could include a separate file like pluggable.php that we could load as early as we load plugins, and therefore could override pluggable functions. Aside from this being a bad idea (see the first four paragraphs of this comment), it would still not be compatible, because up until the setup_theme hook, one could override which theme is to be loaded by filtering stylesheet and template values.
Unfortunately, this just isn’t tenable given how WordPress is architected. The good thing is, there are countless (better) ways to do it.
(Originally posted here: http://core.trac.wordpress.org/ticket/2479#comment:5)