И то и другое я давно включил в свои приложения в качестве стандартного сервиса любого dw
(местами ограничено по логическим соображениям)

Те пользователь может конструировать любое условие из колонок окна + дописывать
свой фрагмент where условия для sql или фильтра dw - что ему больше нравиться.

Результат по моим наблюдениям получился лучше для where в sql -
С фильтрами есть непонятные глюки - ну может я не все там доработал...

Что касается длины where условий - я их ограничил 8к - с диагностикой типа "Слишком сложно...", поскольку с SQL ANYWHERE старых версий (5.5 - 7) были преценденты жесткого падения сервера, когда user маркировал этак 30 000 записей справочника номенклатуры и
накладывал это условие на какой-нибудь товарный отчет.

По поводу эффективности списковых условий IN (1,2,3 ...) применительно к той же ASA
"несколько" по ключу оч хорошо
"много" даже по ключу оч хреново когда все одно full scan получается

поэтому почти везде заменил список на строку через запятую и locate(...)>0 в ней
Ничего лучше для передачи списковых аргуметов в отчеты и процедуры не нашел - это
самое быстрое оказалось - лучше IN, LIKE ...