If it would be helpful, I can run it through Companion and see what else it balks at besides the gotos and report the findings here.
Sure, it would be good to track feature requests. Keep in mind that except for bug fixes and easy/low-risk changes, I probably won't have much time to work on Companion in the future though.
I could manually rewrite/rework the generated scripts and change the gotos to use proper looping constructs (I think, not sure) but I was really hoping not to do that.
It's not easy to do robustly (speaking from experience working on the decompiler). That's probably why Zork's decompiler uses gotos. Although handling gotos in source code is likely easier than jmps in asm, since gotos always go to a specific statement (whereas jmps can jump into the middle of a group of instructions that might normally comprise a single statement, and so you have to figure out how to decompose that properly).
Not to mention I'm maxed out on heap space and I know that Companion typically consumes less heap than Studio.
Companion generates scripts that use about 10% less heap IIRC. Have you verified that it's due to the size of your scripts, and not because you're forgetting to unload certain scripts on room changes?
Also, SCI1.1 significantly increases the amount of heap available, since the script logic is no longer in the heap (just the local variables, strings, and class/instance properties and method lists). Oh, but of course there is no parser in SCI1.1.