Goroutines and lexical closures create a dilemma for embedded targets. Go was designed around the notion that using goroutines (threading, basically) should be effortless and employed without hesititation. Lexical closures is a critical aspect of that, and by extension GC. Both goroutines and lexical closures require dynamic allocation, at least when combined with some other Go design decisions (e.g. seamless recursion, dynamic method invocation, etc).

Go does a great job of making these impose minimal cost, both technically and cognitively, on typical platforms, from server (including many "embedded" server environments) to desktop to smartphone. That's why it has such a sophisticated yet largely transparent user space threading layer. But it's very difficult and usually impractical for Go to target extremely resource constrained environments without exposing and crippling it's core abstractions. Some people are willing to contort Go to fit that space, but perhaps that's because their vision of what makes Go, Go, differs from the creators' and core maintainers' understanding of Go.