This does make sense. The CPU delays executing an ISR if the task code (or kernel code) has masked interrupts temporarily. The CPU also delays executing an ISR if a higher priority ISR happens to be executing. So the delays (often called ISR latency) you are seeing are probably normal – I assume the delays are relatively short.
Agree that you have some evidence of strange context corruption, but if FreeRTOS is contributing to the problem here, I’d be surprised. A “common” culprit of such things is if FreeRTOS’s interrupt vectors aren’t installed correctly. I think this issue is on the FAQ too though, with 3 #define statements in your FreeRTOSConfig.h file typically resolving the issue. On a “legacy” system like yours I guess I wouldn’t expect this kind of error. Worth a look though. (How many tasks do you have?)
Another suggestion for you. Most of the stimulus you have discovered to eliminate the hard faults also results in fewer calls to the RTT output or at least in changes to the timing of those calls. RTT code is not thread safe – not safe for reentrant calls – unless you make it safe. For example, if the RTT system is in the middle of sending something to the terminal and then the framing error occurs, your current code reentrantly calls the RTT system. That could easily cause memory corruption.
If I were you, I would eliminate all calls to the RTT system and then try everything (else) you’ve got to make a hard fault happen. At least you can disprove the RTT theory that way.
If it’s the RTT system corrupting memory, then perhaps the memory it corrupts has more significant consequences when FreeRTOS is used versus when it is not.