It will simplify things for them to have a "no timelocked transactions" policy on their terms of service, and an "if you send us a timelocked transaction, we will not process it so please email us for refund instructions" clause.
You are confusing different concepts here. There are timelocked addresses and timelocked transactions.
In the case being discussed here, the address itself is timelocked by nature of the OP_CHECKLOCKTIMEVERIFY code in the script. Only the person who owns the address can set up an address in this way. Any and all coins sent to such an address cannot be spent until after the desired block height or Unix time.
Then you have transactions which can be timelocked by nature of the nLockTime field in the transaction. Only the person(s) who is creating the transaction can set up a transaction in this way. The transaction cannot be broadcast until after the specified block height or Unix time is reached.
A merchant doens't need a "no timelocked transactions" policy. They simply won't set up a timelocked address locking themselves out of their own coins (because why would they?), and since timelocked transactions cannot be broadcast until after the timelock has expired, if someone tries to send money this way either the merchant will receive it normally, or the transaction won't broadcast at all.