A is probably making use of 802.11 Power Save mode, where it turns its receiver off between bursts of traffic and lets the AP queue up packets for it until it wakes its receiver up the next time, at which time it checks in with the AP to get its queued packets, and processes them.
Most vendors implement 802.11 Power Save in a way that they keep the receiver awake while it seems like a burst of traffic is going on, and then put it to sleep when there has been, say, a beacon interval (~100ms) without any traffic sent or received.
So when A transmits a ping to B, B is always awake and gets its response back within 5ms, before A puts its receiver to sleep.
But when B transmits a ping to A, A's receiver is asleep already, and doesn't wake up for a few beacon intervals, and then wakes up, gets B's queued-up ping request from the AP, and then sends its ping response to B. Since the
ping command sends pings once-per-second by default, A's receiver often has plenty of time (several 100ms beacon intervals) to go to sleep before it gets the next ping request.
The exact timing of how long A sleeps, and how that lines up with the once-per-second pings, could cause a "phasing effect" or kind of periodical oscillation in ping times. Also, other traffic that A needed to deal with may keep A awake longer sometimes, resulting in shorter ping times sometimes.