In case of Tx conflict on the ble interface, the _send function of gnrc_nordic_ble_6lowpan.c will return an -EBUSY error but no one handling the GNRC_NETAPI_MSG_TYPE_SND will take care of the error and what needs to be done for the packet(free or requeue).
This packet will stay in the alloc buffer.
After some time, if such conflicts happened, the memory allocated will continue to grow till the gnrc packet buffer will be full.
This can be reproduced with the microcoap_server example and sending pings forever. At some point, the buffer will be full and the stack will not be able to handle the ping echo request and reply at all.

One easy workaround is to accept to loose packet when there is such conflict and freeing up the packet.
In https://github.com/RIOT-OS/RIOT/blob/master/pkg/nordic_softdevice_ble/src/gnrc_nordic_ble_6lowpan.c#L139
add a call to release the gnrc packet buffer:
if (ble_mac_busy_tx) {
DEBUG("_send(): ble_mac_busy_tx, dropping packet\n");
gnrc_pktbuf_release(pkt);
return -EBUSY;
}

With such "ugly" workaround, the memory leak will be dramatically reduced and the stack will be able to handle more than 5000 pings without memory allocation issue.
There is simlar memory leak in case of -EBADMSG : https://github.com/RIOT-OS/RIOT/blob/master/pkg/nordic_softdevice_ble/src/gnrc_nordic_ble_6lowpan.c#L149

One better approach will be to requeue the GNRC_NETAPI_MSG_TYPE_SND message for retransmission. This could be done either the _send function or the _gnrc_nordic_ble_6lowpan_thread main loop by handling the different errors returned by _send.

Looking for feedback on the recommendation for properly fixing this.

Note:
1/ to get ping stability, you will need a fix or workaround regarding the uart_write function depending on how much debug you have activated. See #5954 .
2/ there is still a remaining memory leak after this, not yet understood by with a lot lower magnitude because it is only 8bytes once in a while and there is usually an hard_fault happening before the memory allocation buffer is full.