The condition sell.listingTime <= buy.listingTime present in the function _canMatchOrders can be easily forged by an attacker after seeing an existing order to determine which branch of the if condition to take.
This isn't particularly relevant to the available matching strategies, since both (721 and 1155) are commutative in the implementations of canMatchMakerAsk and canMatchMakerBid (and also their arguments can be switched without affecting the result). But this may become relevant in the future when more strategies are added, which is to be expected. The design of the IMatchingPolicy interface also indicates the possibility of non symmetric implementations of canMatchMakerAsk and canMatchMakerBid.
For example, a seller can create an order with listing time t_sell and later an attacker can create an order with listing t_buy so that t_buy < t_sell, switching his role from taker to maker.
The effect here is that the attacker can benefit from deciding which policy to use (since the policy is instantiated from the maker side) or deciding between the role maker/taker by simply setting the listing time.
Unsure what could be used to determine who is the maker, in particular in this scenario where orders are not registered on-chain. I guess the options are 1) take this into account while designing matching policies acknowledging this may happen or 2) change the design of matching policies so that it doesn't matter which side is the maker/taker.