That's not surprising. 

The sort is for the results of the merge join between tbSPT and tbTechnical_Details, which is on spt_ref_no=[Opportunity Reference]. That output will be ordered by the value of those columns, so to do a subsequent merge join on technical_details_id will require re-sorting the output by that, no matter whether there's an index on techincal_details_id or not.

If the join on technical_details_id were performed first, then such an index could be used, and THAT sort would be avoided, but then any subsequent merge joins on a different column would require a sort.

If you really just want to get rid of the sort, you could force a hash join, since it doesn't require sorted inputs. Of course, you have to be careful for a couple reasons. 

First, SQL Server likely considered such a plan, and estimated that it would be more expensive. It might be wrong, but it might also be right, and the plan with the sort+merge join might be the best option.

Second, using a join hint will force the exact join order you've written, so SQL Server can't rearrange the inputs to a more efficient order if one is available.

Also, keep in mind that the costs are just estimates; it's likely the sort is indeed the most expensive part of the plan, but that should not just be blindly assumed based on the estimated cost.

Finally, >5 minutes seems quite high for the number and size of rows being processed.

What are the specs of this server? Any chance you could collect wait stats for this query while it's running?

Cheers!