Thanks for the update!
Yeah, if the estimated row counts after updating stats and forcing a recompile of the query are still wrong, it sounds like the cardinality estimator isn't up to the task on this one, at least with the statistics currently in place.
I'm a little suspicious about the stats, since in the postfullstatsupdate plan you posted, the estimate for the initial seek on _Result188 for CostCenter='00966' is off by more than 20x.
A couple of the subsequent joins also look like SQL Server thinks they're going to be more selective than they actually are, but it looks like the main problem is the 20x underestimation of results for '00966' in _Result188, as that seek gets used as input to several of the joins, so the poor estimate gets compounded.
Without being able to rewrite the code, I think the only real option left is to try creating filtered statistics for the value/column combinations that are so dramatically off, the primary one here of course being for the value of '00966' on the column CostCenter in _Result188.
http://www.sqlpassion.at/archive/2013/10/29/fixing-cardinality-estimation-errors-with-filtered-statistics/ is a nice introduction to using filtered statistics to mitigate this sort of problem.
If you are able to create those statistics and then recompile the query, let me know how the performance and plan look then.
EDIT: I just remembered that you specified SQL Server 2005, which eliminates filtered statistics as an option. Doh!
Given that, we may be running out of options. I'll keep mulling it over, though.