This might sound a bit edge case, but we've run into exactly this problem on DrupalGardens.
Suppose you have an installation profile that enables a bunch of modules, adds sample content, runs cron (as per the end of install_finished()), causing search module to index the display of the sample content. Now, suppose you run the installation task non-interactively, so it happens in a single PHP request.
If theme_get_registry() gets called before all modules are enabled, then when theme() is called in the search indexing phase, it doesn't have access to theme hooks defined by modules that got enabled later, causing both an exception to get triggered, and content to not get indexed correctly.
Probably the most robust solution to this problem would be for theme_get_registry() and theme() to use resettable statics, but that would incur some performance cost, given how large the registry is and how often theme() is called. Perhaps the D8 context core initiative will implement some kind of pluggable renderer that solves this problem cleanly.
But meanwhile, here's a patch that addresses the most common reason I've found for why theme_get_registry() ends up getting called at all during module install and update hooks. For background on this configuration variable, see.
|PASSED: [[SimpleTest]]: [MySQL] 38,711 pass(es).|
|FAILED: [[SimpleTest]]: [MySQL] 38,724 pass(es), 1 fail(s), and 0 exception(s).|
|PASSED: [[SimpleTest]]: [MySQL] 38,723 pass(es).|
|FAILED: [[SimpleTest]]: [MySQL] 38,711 pass(es), 1 fail(s), and 0 exception(s).|
|FAILED: [[SimpleTest]]: [MySQL] 38,144 pass(es), 37 fail(s), and 45 exception(s).|