also, it's very cool they're still being maintained!
At very least, C++.
"C++14 For The Commodore 64"
This presupposes that you're doing string manipulation and raw memory moves. I don't know about other people's code, but in my own experience neither of those things are likely to be happening in embedded code. You're much more likely to pre-allocate all your memory, and use zero-copy patterns where ever possible. I never used a C-string in relation to talking to peripherals (i2c, spi, register mapped) or when doing dsp. Moreover, if you do need to use memcpy it's probably because you are doing something very low level for which memcpy is the best choice.
MISRA and similar exists for a reason.
I will leave it to others to fill out the cons. One obvious one is that C does not reflect the parallel compute nature of modern targets (e.g. SIMD) but neither do most serious alternatives.
I do think the time is coming (if not already here) where it would be judged legally negligent to professionally employ C in new systems for certain use-cases (network facing, high assurance, ...). At least not without complete formal verification. I'll leave it to the actuaries to work out where the tipping point is.
C trades very fast execution for rather slow development, especially of larger code bases, if you want correctness. It's fine for tiny programs though.
(Ruby, of course, has its own set of jolly footguns, as any dynamically typed language.)