I'd have to get a more detailed packet capture and reference some RFCs, but given DHCP isn't manditory, I don't think it would be harmful to the mac or network as long as the client's DHCP lease was still valid when it pulled this stunt, otherwise you could get multiple clients claiming the same IP address.
From a security standpoint rather than only revealing just your most recently DHCP-assigned address, you're revealing both the mac address of the nearest layer 2 device and gateway ip of (some nonzero number of) networks you've recently connected to. If a hostile network were to monitor the arp requests to successfully emulate a network the connecting mac had recently been connected to, the IP traffic prior to DHCP ACK that was abridged in the article would probably be sent again. Not knowing what it contained, I can't speculate as to if it would be any different than the network communication that would be done if connecting to a new network.
(Even if everything else was application traffic, I don't anything about the udp/192 protocol for airports, but it may be spoken with assumptions made about the connected network and a vector worth exploring).
If the ARP comes back with the cached MAC address for that network, the Mac continues using the valid DHCP lease it was given. It sends a DHCP request to renew that lease, and I assume would reconfigure the interface if the request fails and discovery has to start over.
From my recollection of the DHCP RFC, if a server hands you a lease for one week, you're allowed to use that address for a week, even if you go offline for 3 days in the middle. In practice, this may not be the case.
I could be wrong about this, as I haven't analyzed actual arp requests in ages, but from the article it appears the arp requests are unicast to the (at least in the example) cached MAC for the gateway.