Sender Information Not Cached on the Receiver During an ARP Request

I'm currently trying to get my head around more advanced networking concepts. The way I am doing this is by going on one of the servers I look after as a sysadmin and running network captures to see and make sense of the data. (The machine I am running this capture on is serveriamon.networkname.local with an IP of 172.16.2.7)

This lead me to this exchange on the network:

1127    11:46:55 12/10/2012 30.2960887      172.16.3.30
serveriamon.networkname.local   ARP ARP:Request, 172.16.3.30 asks for 172.16.2.7    

1128    11:46:55 12/10/2012 30.2961939      serveriamon.networkname.local   172.16.3.30 ARP ARP:Response, 172.16.2.7 at 78-2B-CB-23-8D-07   

I can understand this exchange. The Machine at 172.16.3.30 wants to find out where and what the MAC is for 172.16.2.7. The server at that address (this server) replies with its ARP response containing the Mac address.

Immediately afterwards this frame then occurs:

1129    11:46:55 12/10/2012 30.2964210      172.16.3.30 serveriamon.networkname.local   SNTP    SNTP:NTPv3 Request, Leap = 0, Mode = 3, RID = 5154  {SNTP:377, UDP:376, IPv4:375}

This I understand is a request for the time on the server. That's fine. The next frame is what is confusing me:

1130    11:46:55 12/10/2012 30.2972641      serveriamon.networkname.local   172.16.3.30 ARP ARP:Request, 172.16.2.7 asks for 172.16.3.30    

Embedded in frame 1129 in the SNTP request is the source address. Why is the server then immediately doing a broadcast to find out where the IP address is?

I suspect I am just misunderstanding how this works but I am genuinely intrigued. It seems "wasteful" and "noisy" to put out an ARP when it should already have the information?

This is an interesting observation that I have never noticed before. This behavior suggests that the server isn't putting the Hardware address into its arp table when it gets arp requests. What type of operating system is this?

The original ARP RFC 826 does talk about this a little bit with regards to a "Merge flag":

"Notice that the <protocol type, sender protocol address, sender hardware address> triplet is merged into the table before the opcode is looked at. This is on the assumption that communcation is bidirectional; if A has some reason to talk to B, then B will probably have some reason to talk to A."

I'm having trouble finding more information about the merge flag though.

A guess as to the reason for this behavior:
One reason I guess you might do this is to prevent someone from overflowing your arp cache. In other words "To be safe, I'm only going to cache this if I asked for it".

Otherwise, people could maybe craft a bunch of arp requests with lots of different IPs and fill up the table (lots of other ways you might prevent this, but this seems like a simple way that would work).