Yes, size matters. Your co-worker's argument is that any amount of traffic up to the MTU will take the same amount of time to transmit, and that simply isn't true.
Forget for a minute that you have any protocols at all, just a pipe where bits go in one end and (hopefully) make out out the other. If the pipe can transfer 8,000 bits per second, 500 bytes (4,000 bits) will take half a second and 1,000 bytes (8,000 bits) will take a full second. This holds true for pretty much every kind of interface because they're all serial. Some interfaces are partially parallel in that they may let you transfer more than one bit per clock cycle, but once you've exceeded that limit, you're serially transferring a stream of whatever those units are. So there's one basic limit right there.
When you add protocols, which are necessary because pipes aren't always reliable or you have lots of pipes that form a network, you add information that tell the protocol implementation what to do with the packet. That information takes up space (and therefore transmission time) that you can no longer use for data and is required overhead, because you can't run the protocol without it.
Your example is a UDP/IP* packet, which contains your payload, an 8-byte header added by the UDP protocol and a 20-byte header added by the IP protocol. If you send 500-byte datagrams, the 28-byte overhead imposed by the protocols will make up 5.3% of the 528-byte packet that has to be sent. Increase the payload to 1,000 bytes and you're sending more of your own data in each 1,028-byte datagram for an overhead rate of 2.7%. If you had a transmission medium that had a large MTU and could swallow a 10,028-byte packet, overhead would shrink even further to 0.3%.
TCP, being a more complex protocol than UDP, has a 20-byte header, which makes the total overhead 40 bytes when run over IP. For your 500- and 1,000-byte payload examples, overhead rates would be 7.4% and 3.8%.
Sending those TCP/IP or UDP/IP packets over Ethernet adds 14 bytes of Ethernet's own header, four bytes of its trailer and 12 bytes of idle time between frames for a total of 30 bytes. As it is with the protocols above, larger payloads mean fewer frames and fewer frames mean less time spent on overhead.
There are a number of reasons why you don't just send arbitrarily-large packets to keep the overhead down. The biggest of those reasons is that you don't want to have to retransmit a whole megabyte of data because you lost six bytes somewhere in the middle. Unless you know your transmission medium is extremely reliable, it's much better to incur the overhead so you only have to re-send a one-kilobyte frame.
The real-world parallel to this would be using 53-foot trucks for shipping. It's a lot cheaper to pack each one as tightly as possible than it is to hire drivers and buy gas for a lot of them to carry just a couple of things each.
*What is commonly called UDP is actually UDP over IP or UDP/IP. UDP can actually be run on top of protocols other than IP, but IP is by far the usual case.
To address dbasnett's comment: The point isn't that UDP is run on top of other protocols, it's that its place in the protocol layer cake means it can be. UDP, being a transport-layer protocol, assumes host addressing has already been taken care of by the network layer. This means you can run UDP (and just UDP, not UDP/IP) across pretty much anything if your only needs were to identify sending and receiving ports. A serial link between two hosts (with no network layer, since addressing would be implicit) would work. Ethernet frames would, too, if MAC addresses were sufficient to identify hosts. I'm not saying anyone actually does this, but a properly-designed network stack will allow replacement of lower layers without the higher ones having to know or care.
Best Answer
The UDP protocol does not guarantee that messages are delivered in order or delivered at all, but it does ensure that those messages which do get delivered are complete and unchanged by automatically including a 16-bit checksum. That means adding another 16-bit checksum on the application layer is usually redundant.
...usually....
First, with IPv4 (not IPv6), the checksum is optional. That means you might be using an exotic configuration which doesn't do checksum generation and validation (but in that case you should rather fix your network stack instead of jury-rigging this on the application layer).
Second, with a 16bit checksum there is a one in 65536 chance that a completely random message happens to have a valid checksum. When this margin of error is too large for your use-case (and in the defense industry I could imagine several where it is), adding another CRC-16 checksum would further reduce it. But in that case you might consider to use a proper message digest like SHA-256 instead of CRC-16. Or go all the way and use a real cryptographic signature. This protects not just against random corruption but also intentional corruption by an attacker.
Third, depending on where the data comes from and where it goes to, it might be corrupted before or after being sent over the network. In that case the additional checksum inside the message might protect the integrity of the message further than just between the two network hosts.