I agree. I find myself disengaged as soon as someone makes fun of the hard work of others. Intelligent people don't typically do this.
> Rationale: It is very difficult to make goto work well with defer and implicit unwrapping of optional results. It is not just making the compiler harder to write, but the code is harder to understand as well.
That seems to fit your heuristic. Goto being difficult to implement in the compiler doesn't match expected reality.
So seeing someone say that their compiler struggles to represent goto throws some doubt on how the thing is implemented. Goto should generally be the easiest possible control flow to translate into your IR.
And you might say "so what, the compiler can be complicated, just make the language easy to use". However, one design constraint is to not make the language hard to reimplement.
And you might not agree with that constraint, but some people feel that this is indeed important. Important enough to not include `goto` as long as the use cases of `goto` are all covered.