Embedded systems range from the tiniest microcontroller up to multi-core xeons, DSPs and FPGAs.
Embedded != small.
The typical issues associated with embedded development are 1) cost and 2) response time (for real-time embedded systems).
The big one here is cost. If you're wasting a single byte in your code, you have to pay that cost in every single unit you make (e.g. millions).
http://www.militaryaerospace.com/articles/2010/04/aonix-perc...
http://www.militaryaerospace.com/articles/2009/03/thales-cho...
Also I have a JVM running on the Cisco phone on my desk and the Ricoh laser printer down the hall.
Just, because there is a portion of the market that a certain concept doesn't apply, it doesn't mean it isn't viable in other segments of the same market.
For Go to be successful on embedded systems, doesn't mean it must run everywhere.
Heck there are even embedded CPUs that cannot cope with ANSI C, and that hasn't prevented people to make use of it on other market segments of the embedded space.
Far as GC's, it's also about size if it's a constrained embedded system. I've seen a number of GC papers discussing tradeoffs between size (i.e. RAM use) vs speed/latency. This even factors in a bit on the large ones like Vega where they were still balancing those factors to get an optimal, "pauseless" GC for accelerating enterprise apps.
I agree on the other points.
Also embedded real time JVMs fit in a few hundred KB and are being used by the likes of military, e.g. Aonix picoJVM, to control real time stuff like battleship missile tracking systems, which I assume is quite real time.