Yes, mandatory filtering is IMHO a poor choice to stimulate different behaviour of API developers.
It reminds me of a project within a large financial enterprise in which a simple solution was replaced by an extremely expensive and complex one just because a specific construct was not allowed. Although functional equivalent, it was the equivalent of generating new types of Turing machines with additional capabilities. It will work as long as you accept computation time and resources to increase polynomial 
A related topic was raised by another user on Mandatory filtering on single and bulk endpoints where sync APIs are available.
However, the announced changes bring along many more contingency risks and expected issues which the SQL engine can not be accommodated for at this moment.
Given the uncertainty of the outcomes and risks involved of the announced changes in the Exact Online API we have had the unpleasant need to change the subscription conditions on Invantive Data Hub and Invantive Data Replicator. Not all users have yet been informed, but please consult Wijziging condities Invantive Data Hub en Invantive Data Replicator.
The essentials is that Invantive Data Hub and Invantive Data Replicator users will either not receive support on Exact Online from July 1 onward covered by the subscription to allow Invantive to enable changes to be made starting July 1 to keep the other Invantive products running, or stop using the products altogether.
For some deployment scenarios of Data Hub and Data Replicator we will describe alternative possibilities using Invantive Cloud. Please read for example Store Exact Online data in an on-premise SQL Server through Invantive Cloud.