In chapter 5.12.2.1 it is not clearly specified whether, in case of an invalid filter, the server must return an error code directly in the response, or whether the MonitoredItem can be created and an error code is returned in the Publish response. For the UserAccess and the IndexRange this behaviour is explicitly allowed and described in chapter 5.12.2.1.

Excerpt from the specification:
When a user adds a monitored item that the user is denied read access to, the add operation for the item shall succeed and the bad status Bad_NotReadable or Bad_UserAccessDenied shall be returned in the Publish response. This is the same behaviour for the case where the access rights are changed after the call to CreateMonitoredItems. If the access rights change to read rights, the Server shall start sending data for the MonitoredItem. The same procedure shall be applied for an IndexRange that does not deliver data for the current value but could deliver data in the future.

If there is no technical reason that the error code must be delivered directly in the response, we believe that the PublishResponse option should also be explicitly allowed.
The CTT test expects the error code directly in the response in case of an invalid filter. However, this behaviour does not take into account, that the data type of a variable node can change and the filter can therefore become valid. This use case is possible on our system and should therefore be considered.