Just a quick update on the issues I described above, if someone stumbles by
I was able to trace down the cause for the crashes I had when the receiver was operating at its sensitivity level (weak signal). It was indeed related to the "packet length byte" associated with the data payload getting corrupted.
After some poking around in the AIR library I found that that the CC1101 packet length configuration was set to 61 bytes. In my sketch I had only reserved 10 bytes in data memory for RX data, because I was only sending 10 bytes. My confusion around that was that with the AIR library, you specify in your sketch how many bytes you are receiving each time. I had set this value to 10, believing that the packet handling then would be done using this value. I was wrong, under the hood of the AIR library, it was still accepting packets up to 61 bytes long.
So every time the lengt byte was corrupted to a value between 10 and 61, some other data was overwritten by junk (packets with lenght byte > 61 bytes is automatically discarded by the CC1101 packet handler with the AIR library).
The simple fix was of course to increase the rxdata space to 61 bytes, I had a simple application and using the G2553 with enough RAM. Doing this, I got what seemed like a rock stable application even at an RF level where most of the packets was corrupted due to poor signal to noise ratio.
Not terribly happy with the AIR library, but I guess it wasn't really made for tinkering too much, just running the example sketches as is...
Edit: I see that the OP has made the same mistake as I did, he is only reserving 50 bytes in data memory for RX data. So his application will be more stable than mine, because its only packages with length between 50 and 61 that will crash his application.