It does indeed sound temperature-related, but at only 23 °C, I would not expect a problem.
Here are a few thoughts:
The next time, can you try measuring the 3.3 V rail, if it’s accessible?
If it fails regularly, or you can reliably provoke a failure, can you run it without the radio module (in software - don’t try to unsolder it, just comment out the one line send_rf_data();) and see if it still fails? (OK, I know you’ll be without output - but does the LED still flash?)
Monitoring the serial output while you do this might actually confuse the test, since it will run on 5 V from the programmer as well as from the USB.
Is it a power supply problem - how are you resetting it? If you’re pressing the reset button, it might not be, but if you’re pulling the USB connector out, that would reset the internal regulator i.c.
Have you removed the jumper link (JP2) to force it to use only the USB power? That power regulator should shut down on over-current or over-temperature, then reset itself after it has cooled. Can you confirm it doesn’t come back after a break?
Does it still fail if you use a different port on your USB hub?
Could it be a brief brown-out on your 5 V USB power supply - sufficiently low to foul up the RFM69 but not low / long enough to cause a full and clean restart?
Although the emonTH and emonTx are similar beasts, that the TH doesn’t fail is not cast iron evidence that the TX won’t given the same treatment.
If nothing above points us towards a fault, then as you’re using mains power, it would be possible to modify the sketch to give it a watchdog timer, and that would cause a software reset of the processor (but not of the RFM69CW).