OP hasn't addressed the fact that UDP will willfully drop packets and send them out of order. What if I need to stream some data? What if I care about the order my IPC messages arrive in?
I agree this might not be the best method of dealing with out of order reception of packages, but it does exist in the protocol.
You shouldn't drop packets on single machine unless you are sending a lot of them and run out of buffer. Buffer size is also tunable if you do have issues like that.
If you need to do things over the internet it would probably be best to do OSC over TCP.
[0] https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...
I think the point is just to say that the article shouldn't tout plain UDP as a fix for TCP being hard in certain languages without calling out the downside.
That said, most protocol implementations that I'm aware of over UDP have one or more of "retry/order checking/etc" on top of them. Like NFS, Bootp, tftp, etc.
But it's a common false belief that it would be "reimplementing TCP". Some guarantees of reliability are required for most practical applications but TCP's "in-order stream of bytes" isn't suitable for everything.
For any kind of real time data, when packet loss occurs, TCP will re-send data that may already be outdated, and causing later packets to arrive even later. In real time uses, TCP makes any networking problems worse.
It's also worth noting that under ideal conditions (ie. no packet loss), TCP and UDP behave almost identically (after startup, that is). The issues only appear when you're working in less than ideal conditions and are worse the longer the physical distances are.