This may be more of an academic exercise than anything. The solution seemed to be adding an index to the zsuspense table.
I found the attached interesting. Not sure if it's a bug in the SQL optimizer, the INTERSECT operator implementation, or what's going on, but it took about 6 hours to generate the attached plan.
Note the number of reads. I don't see where those reads manifest themselves in the plan diagram or the plan tree. Are they hidden?
9348575 rows in zSuspense
8682197 rows in MatchMade_Main
1604438 rows in MatchMade_Details
Reads and STATISTICS IO are not necessarily apple-to-apple comparisons.
Is it possible, for example, that the query triggered an autostats? That would be a potentially high number of reads attributed to your batch, but not accounted for in the statement you're looking at (and if you captured the plan in Plan Explorer FREE, the STATMAN call would not show up in the statement tree/query call stack).