I think the reason for the problem could be that you are somehow not getting data from the SPI. That situation does not look as if it is properly handled. You do have a timeout, but it looks as it is chosen rather arbitrarily, and with repeated cases of no SPI data, you will use a long time entering data into the FIFO. If you use too much time, you will get a FIFO underflow. This is signaled by the RF error interrupt. After this happens, the radio will read zeros out of the FIFO until the FIFO is reset, so the packet will be transmitted, but with incorrect contents. I suggest that you check for this, either by checking bit 0 of the RFERRF register in the loop or by servicing the interrupt. In case of an underflow, the data loop may take more than 1.25 ms, and after this has happened you will thus have an event 1 pending when you start the next Tx.
To prevent problems with the loop taking too long, you could also check for TASKDONE in the loop and break out if you see it. It is also possible to use the Timer 2 period interrupt flag or the Timer 2 overflow counter to check that you have not used more than 1 period for the transmit operation.
If the problem is indeed lack of SPI data, the next step is of course figuring out why. It could be a problem with the way you handle SPI Rx in CC2543 (I haven't looked into details on that), or a problem with your SPI master. When you control power to the CC2543, will this also impact the SPI master? In that case, I suppose the differences you see could have to do with that device. Even if you power the two devices individually, the I/O of the CC2543 will behave differently during reset depending on the reset method used, which I suppose could affect the SPI master.