Filter conditions is not a problem.
Storing filter conditions as data, and then applying a selection of these filters dynamically, are.
There are logical/functional issues. E.g. filter on sales to customers in a specific region. This filter requires the sales table to be joined to the customer table (get customer), and the customer table to be joined to the address table (get customer's shipping address), and that joined to region table (get region name).
So how do you design the report filter interface to only do these joins when this filter is used? And not to do these joins when the filter for (sales > 500) is used?
If 2 filters have an overlap in join requirements, the same columns will be in multiple tables. How do you determine which column from which table to use in the SQL projection?
There are technical issues - like dynamically determining what joins a filter needs. Like supporting bind variables for a filter. Like knowing when to outer join and when not.
And so this list of complexities goes on and on and on...
If you argue that these filters are not that complex, then thanks. You have just provided the evidence as to why there are no valid reasons for storing filters as data. If they are not that complex, use code for the filters - not data.