For TCP/IP, the matter was "decided" the first time an IP packet was sent. The order of bits and bytes put onto a wire (or a radio link) by the sender had to match the order they were processed by the receiver. If the receiver processed them in a different order, chaos ensued.
Since all communication involved at least two parties (a sender and a receiver), the appropriate order was established by convention. If you followed the convention things worked; if you didn't then things didn't work.
Eventually someone saw fit to actually specify the conventional order in an RFC, but before that you could figure out what the correct order was by trying to communicate with another already-working system. I would not be surprised if repeated failures due to incorrect assumptions is what led this to being included in RFC 791, when it had been unstated in RFC 760 and IEN 123.
Keep in mind, it was not typical to write the RFC/IEN first, then build a system afterward. Rather, you built a prototype first, refined it through multiple iterations, and then when you finally had something that worked well enough to share with others, you would document it in an RFC or IEN (although sometimes you'd do so even if it wasn't working "well enough" simply to meet a commitment).
YY-MM-DD hh:mm:ss.ddd
isn't a very interesting answer. – wizzwizz4♦ Apr 11 '17 at 8:01