Well changing parameters makes it hard for the query to get a good query plan. I try to write a good query that is efficient and then add all the parameters. If things are really bad you may need a DBA or DBA Dev to look at indexing and statistics, if those are wonky nothing you do is going to help.
Testing has multiple phases. You can execute the stored proc from SSMS, check the query plans and look to see what is happening. Then you still test again once you start triggering the proc from within a report in SSDT. And you would test it again once it is setting on the server.
When I have a lot of parameters I tend to use tables (this time temp) like you did, but I use function to split the values. I check to see if they have selected "all" (I have added that as an option.)
--IF SSRS PASSES IN ALL CHANGE TO NULL ELSE POPULATE TABLE WITH VALUES
IF @STATUS = 'All'
BEGIN SET @STATUS = NULL
INSERT INTO #STATUS
Then my where clause
((@STATUS IS NULL) OR ([Status] IN (SELECT ITEM FROM #STATUS)))
This eliminates the filter if you are not using it. Does it save you a ton? Not sure it depends.
I am not sure what exactly you are working on but is it possible to use sub reports to bring more detail? This will offset some of the processing to another report.
Your truncation error might be due to a data type issue, max limit is something I haven't run across and I have messed with some SCSM reports with 26+ parameters. NUTS!
Learning to be a SQL DBA one day at time.