This behavior is typical seen by problems with arp resolution. I don't know if it is your problem but it is worth to look at it. Let me explain.
On a local area network without router (broadcast domain) devices broadcast for ip addresses of other devices they want to connect to with arp requests, typical seen with
sudo tcpdump -n arp:
ARP, Request who-has 192.168.10.4 tell 192.168.10.113, length 28
ARP, Reply 192.168.10.4 is-at 00:0a:e4:02:04:30, length 46
Now the package can go to mac address 00:0a:e4:02:04:30 (destination address of the ethernet frame, that contains the ip frame, that contains the tcp frame ...). To improve performance both devices will cache the mac address from the other side in its
arp cache for 5 minutes by default so only every 5 minutes there is a arp request sent for refresh. If the RasPi has a problem and does not reply then the other device cannot connect - no ping. But when the RasPi sends a request (ping) it gets an arp reply and both devices caches the opposed mac address. The other device is able to ping the RasPi - just 5 minutes long. After disconnecting the interface it gets down and its arp cache is cleared so it also cannot ping the RasPi after reconnect.
So first test to evaluate this: from the RasPi ping the other device wait 6 minutes and try to ping the RasPi. Inspect the arp caches with:
~$ ip neighbor show
And of course you can simply look with tcpdump. If you find that the RasPi does not Reply then you know the reason but it is a bit difficult to say why it fails without deeper knowledge of the network setting. Maybe a missconfigured firewall or wpa_supplicant, interfaces with two mac addresses, buggy interface? Try to set the problematic interface to promiscuous mode and check again. Then it will accept any packages from the network.
rpi ~$ sudo ip link set wlan0 promisc on|off
But this should not be used as a solution if it works. You have to fix the cause.