A great deal of embedded software is still done in C/C++. (Embedded is not a good environment for dynamic languages.)
Being able to accurately profile how much memory will ever be in use is very valuable. Being able to prevent unexpected usage or stop-the-world collection issues means your device is that much safer.
Also, static languages are usually faster and more predictable, to a certain degree. This is advantageous in an industry that would rather spend years developing something than have a small chance of killing someone. Bugs are unacceptable.
If you're willing to pack an Intel Atom or something into your device, fine. But if you can get by with a tiny ARM chip, why shouldn't you?
Features, complexity, cost/availability of humans that can comprehend it, availability of existing software components, simplicity of software development process, etc.
And I kind of touched on the simplicity of software development. Yes, it's possible to quickly shove in a really tiny x86 computer and be done with it, but it ends up being cost prohibitive and energy hungry. Embedded environments are a place where you can get by with a tiny ARM chip; they're power efficient and cost effective. If you're in the embedded field, dev isn't as simple as a REPL, you have to put it directly on your device or otherwise emulate your device in some way. This forces you to come up with robust solutions.
Dev in this environment is already hard. It has to be robust anyway. Maybe we should pick the right tool for the job while we're at it.
And I am happy using a robust solution that I know won't fail me. If you're in a situation where failing to write bug-free code can kill, you would be too. Medical devices are one such field.
(But to each his own, of course! You can do awesome things with any tool.)
Hard limits to processing power, memory, energy availability, etc. do exist in some applications, but the OP doesn't seem to have these issues.
But when I think of embedded devices, I'm looking across my desk at a Cisco router with an eight year old firmware, and an HP LaserJet I recall updating at least 12 years ago. I shudder at the idea of writing Ruby and having it run in production for 12 years.
This doesn't criticise "dynamic" languages directly - but I can only possibly think of C, and similar languages, which wouldn't suffer this issue. Hopefully Rust can improve this situation.
That said, I'm on the fence about Erlang in this situation.