Yeah, what happens is that such code does not pass code review :)
In 99.99% of cases an ISR should only set some flag, that is then checked by code, running in user mode (or whatever it is called for your platform). Then the real work is done in user mode. The remaining 0.01% of cases does not involve using dynamic memory either.
Definitely no exceptions in ISRs. What would an exception really even mean in an ISR context? The "call" is done by the hardware, so there's no stack to unwind. Uncaught exception would practically mean system crash.
Stack usage should be low, because ISR itself might get interrupted by a higher priority IRQ.
ISR (interrupt service routine) needs to return as fast as possible, usually in a few microseconds.
On x86, no FPU or SIMD in ISR either, unless you save and restore the registers. You need to cover all SIMD extensions, current and the future ones. If you use SSE but don't save AVX/AVX-512 registers, expect very weird bug reports. Better to simply avoid.
my point is that there are hidden mutexes in libraries that people often don't know about - his example of replacing new() with malloc() doesn't solve the problem, instead you need to be able to code your C++ without new, or at least the real-time bits of it (and that includes using stuff like strings and their libraries that do new() behind your back, or even printf which can run foul of the stdio hidden mutexes)
It's not just ISRs, priority inversion is a real problem that results in some of the hardest bugs to find (I once had to chase one that happened only once a month, resulting in satellite systems losing their provisioning)
Honestly, these "people" seem like mythical creatures to me; I've certainly never met one. If you're qualified to write an ISR in C++, you're qualified to understand which parts of C++ are valid to use in an ISR and which aren't.
This is a non-problem that does not appear in practice, even though it could in theory.
I'm sure we all know what happens when your ISR quietly does a new while some other part of your code is holding one of the locks deep in malloc.
But far more important is avoiding priority inversions when a low priority thread is holding a lock in a library somewhere, they result in high priority threads missing real-time deadlines - the sort of heisenbugs that are pretty impossible to find .... and are best to avoid by design.