Because they're connected to the network. Seriously.
It's like "why do recursing DNS servers spam queries if they don't get an answer within 10 milliseconds?" To give you an idea how shortsighted this is, a production grade DNS server doing this also supports response rate limiting (warfighting capability which treats the spamming as spam), and the recursing DNS server is supposed to be caching and should be trying to optimize "whole of page" to achieve so-called "happy eyeballs".
To give you a somewhat more technical explanation, a MAC address can be permanently tethered to an IP address (so that each time it connects it always gets that address on that particular network). When that is not done (when there is no association for a particular MAC), an address is assigned from a (finite) pool. In some deployments the finitude of the pool provides a "fusible link" for defense in depth against some forms of resource exhaustion.
The MAC address is visible regardless of whether or not a device is connected to a network: it is an address (it has broadcast and multicast too). When devices are not connected to a network and want to go around mumbling "notary sojack" (with a major 0) to every man + dog + keyhole to see who/what responds there's no downside for them doing it; at least, I haven't seen any hostapd option for running a tarpit like we do for some level 3/4 services (the first attempt is rejected; sometimes the entire TCP handshake is completed and at the app level the server says "not now, try later").
Once they're connected to a network there's a network stack with DHCP, ARP and server state. The set of MAC addresses is orders of magnitude larger than the set of IP addresses in a DHCP pool. It doesn't "hand out an address" as the first order of business; it records your MAC address and gives you an address from the pool. Addresses return to the pool when the lease expires or when they're observed not to be in use. (There is a DHCPRELEASE op but crappy software so defense in depth doesn't rely on clients cleaning up after themselves.)
Once you've got an IP address associated with a MAC address associated with your network interface it looks like a LAN segment on the internet. If somebody on the segment wants to send a packet to that IP address they use ARP to ask what hardware machine code (MAC) do I address a packet to this IP address to? (IP addresses are a layer of indirection)
Beyond that the LAN segment is connected to other segments with a router. The router knows things about topology that you're not supposed to know, and more importantly that random peers elsewhere on the internet aren't supposed to know. If you were on a LAN segment connected with a hub, you'd have some idea what other internet addresses were active on that segment. You can make an educated guess about what addresses are allowed (by the router) on that segment based on the broadcast mask; you could perhaps ping addresses within the broadcast range to see which ones are / aren't in use and hijack one of them.
What happens to packets which are part of a session which are in-flight when an IP address changes? Quite frankly, many applications very wrongly presume that an address (or DNS name, but that's out of scope) is some form of identity. TCP has no way to change one of the addresses mid-session. So you're not going to be changing the IP address with garden variety cloud services.
Now we've got the problem defined: what happens if the MAC address associated with an address changes? First off, packets coming from the router destined for the old MAC address based on the cached IP -> MAC association are going to start dropping. Or be intercepted: what's to stop some joker from grabbing such an address and claiming the "legitimate" holder is the impostor?
(I wouldn't be so sure that you can't see wifi traffic which isn't addressed to your MAC if you've successfully authenticated to a wifi network. It's more like a hub, at least if you're connected to the same AP.)