"The game has no audio, since PLT Scheme doesn't have
audio support."
"I think it would have been considerably easier to write
it in PLT Scheme directly, but the Arc implementation
builds character."
really raise a red flag for me. The first one says the target platform is crippling Arc. The second one says Arc doesn't provide any benefits over the target platform (other than "character building", whatever that is).
That's like a C programmer saying it would have been easier to write something in assembly, or a Java programmer saying it would have been easier to write something in bytecode. (Except assembly and bytecode never crippled an app's audio support.)
I think the problem here is the title. After reading the article, I realise that when the author says Arc "is good for" games he means you can do games at all with a bit of work. The details you mention should only worry you if you expected the author to be proposing that Arc is currently, out of the box, a competitive platform for games.
By the way, you can roll your own audio support in any Scheme that has a FFI. You have to be a bit careful if you want low level access [1], but if you just want a play-wav function you can wrap SDL, fmod, OpenAL, or any other library that gives you audio through a C interface.
The point here is not whether the Arc platform is suitable as-is for games, but whether it's worth the effort to make it suitable. You can amortize that effort over several games.
Neither the C/assembly nor the Java/bytecode analogies are apt IMO. If you can't get access to some underlying platform facility in Java, bytecode won't help. As for C, when you move to assembly you sacrifice platform independence, while when you go down to PLT or the FFI the result is an Arc extension that, if well done, has the same objective qualities as if it had been provided by Arc in first place.
[1] ...since that may imply writing a C callback that may be possibly be called in a separate OS thread. Most Scheme implementations don't support OS threads, but even those don't stop you from (carefully) using OS threads in your C extensions.
That's like a C programmer saying it would have been easier to write something in assembly, or a Java programmer saying it would have been easier to write something in bytecode. (Except assembly and bytecode never crippled an app's audio support.)