That's one of the reasons applications separate data and signaling path (FTP, VoIP, IM file transfers, IRC DCC, etc.). That said, the chat delay shouldn't be that big - maybe a second or two on a really saturated link.
I think they do have a point. Also it's much easier to maintain secure architecture that way. Just test it. If you think the delay is acceptable, it probably is.
I think your best solution would be to not send data and chat through the same channel.
But if you must, you could chunk the data yourself and maintain a send queue. Size the chunks to be small enough to give your "half a second" response time.
When you want to send chat, insert it at a higher position in the queue. You'll have to create a scheme for tagging the chunks to ensure proper reassembly on the other end.
If I misunderstood your problem and you don't need to interrupt data while it's being sent, you can just use a priority queue and mark the chat messages with a higher priority.
Regardless of how you approach it, I think that once you have handed the data over to the API, it is out of your hands and you can't control the ordering.
I'm eager to see if anyone else has a better answer for you. This is an interesting question.