Is there really a "packet out of order" problem, or are you playing loose with the terminology here? That would be a TCP stack problem. Do you really mean when fibs does not ack a command you send too soon after a previous one?
The only protocol related problem I'm aware of is the "run-on" message problem that is discussed in the CLIP documentation. I've never seen a packet out of order issue, and if there is one, it certainly isn't a TCP stack problem, but it could be a threading issue in the FIBS server software. But again, I have never heard of such a problem.
It may be that a client sends a flurry of messages together, and I seem to recall that it is possible to overload the server's message processor so that some of the messages are discarded. In general, it is better to throttle packet sending somewhat to avoid that problem.
Of course, if we had access to the server code, or there was someone who cared about it, we could know exactly what goes on in the server.
CLIP was made to be more parsable, but these days there is no shortage of cpu and higher level languages to parse with, so building a non-CLIP protocol client shouldn't be that bad.
CLIP offers other advantages over the non-CLIP protocol, mostly around better information about logged in users, and there is little reason to not use it. However, if the intent of this retro client is to just display messages, the formatting of the non-CLIP protocol is more human-friendly.