You've got a two second compile time on a query that's not all that complex. But, you're referencing six tables and the optimizer is only pulling data from four (plus that odd table spool). So, it looks like it's going through some simplification for you and eliminating some of the tables you have referenced. First tuning suggestion, figure out what that is and why and eliminate it from the query. Next up, estimated cost is 49.3946. That's not terribly high. Granted, SQL Server thinks it's moving 100k rows, but that's not that much. Maybe test out with the cost threshold for parallelism set to 50. Are the statistics up to date? When was the last time you had a full scan on them? I ask because that nested loop join looks odd considering the amount of data we're moving and a clustered index seek for 100k rows, that's a very strong indication that you're looking at out of date statistics, which makes the whole plan suspect. Also, if you created an indexed view, that's not being used, instead of all those nolock hints (you do know that can lead to missing/extra rows, right?), try a noexpand hint and run the query directly against the indexed view (which may still need to be rewritten since not all the tables are actually used).

That's a quick pass. I'm sure there are more details to pull out of it. For example, why a table spool?