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.