Just by looking at the code constructs, I recognise I do use this technique sometimes, but with severe moderation. Just in cases where there are other, more straightforward filters present that will reduce the result set before the 'dynamic' conditions have to kick in and only if those conditions themselfs are trival.
Even if you use variables to make the input and thus the selections dynamic, the query plan by default will be optimized for exactly the input values you hand the optimizer the very first time you invoke the query. Assuming you use parameterized queries, which you should. To treat all input equal, every time, SQL Server 2008 introduced OPTIMIZE FOR UNKNOWN, as an query option:
( optimize for unknown )
The optimizer not being able to throw away a conditional condition (yes i wrote it), does not make it sargable. For that it would need to be able to make use of an index of sorts to narrow results and seek/filter quickly. A variable by very nature is not something to be searched in (excluding table variables), so calling it sargable is kind of odd.
You should examine in a big test case, how many pages are read and if this matches what you predict based on expected behavior to make sure you have the desired effect. If it does not and reads more then expected amounts of data to filter, you just have a syntactically convienient way of having many conditional conditions.
The alternative of Dynamic SQL written in a stored proc, I do not like much either, as that too is messy to maintain code wise. I myself add/remove conditions in the application layer where it is more natural and can be even more dynamic. At least in the language i work in, but with some concessions that same technique can be made to work in just about any mainstream language quite well.
I am also not really a big fan, nor frequent user of stored procedures. But understand their role in other scenarios then mine where there is no proper alternative. In such cases I would go for the dynamic SQL solution for complex cases and for simple ones stick to conditionally select a query. Either solution is just a wrapper really and thus overhead by very nature.