It runs fine. It is perhaps a bit pricey for a 200MHz system, I'd certainly focus on having only a few of them and doing most of my work by looping over some sort of user-defined tasklet (or, in other words, "standard game architecture"), but it's not like Go requires multiple CPUs to work at all.
I didn't say it would not run and I am happy that Go is being used in gaming like this. But it's like buying a Koenigsegg and using to to drive into your near by grocery store as concurrency is at the heart of Go and having it run on a single core, or rather, i assume, thread, is not the best use case for it.
I'm actually not a big fan of people who recite "concurrency is not the same as parallelism" like a mantra because I don't think it's anywhere near as orthogonal as those people think. But then, that's also largely because multicore is the norm now, rather than some bizarre exception. In a single core case, it is still true. Goroutines are just a different way of achieving async functionality, in a way probably a lot more convenient than the actual code of the time had, albeit at a bit of a performance penalty.
There was a period of time towards the beginning of Go when you could get some small performance advantages for certain tasks by locking the runtime to one goroutine at a time. They've long since addressed that, but there was a time when there were people writing Go code and deliberately limiting it to one execution context at a time.
"concurrency is not the same as parallelism" is a "mantra" exactly because most people are unable to distinguish between them and/or understand the meaning. maybe not nowadays, but go back a decade and that was definitely the case.