I don't know about OpenBSD and LLVM, but Go has made good on the Go 1 compatibility promise, with only a few minor changes being disputed as wether they break it or not.
Go 2.0 will probably be a different story, assuming it ever comes out, but I have a hard time believing the devs will release anything that won't be fixable using the "go fix" tool.
I can only comment on the specific llvm case, but I cannot say "it works" without listing the fact that I have to keep ~5-6 versions of llvm around _exactly_ for that reason.
You cannot compare an OS, or in general any product which is "complete by itself" (browsers), with a compiler which is then used to _make_ the end product. Your source depends on it, and as it grows it just becomes increasingly hard to keep up.
Rolling releases are /also/ a tradeoff. I'm not particularly pleased with llvm in this case. I genuinely prefer semantic releases, and yes, even the python2->3 strategy in this context.
Firefox used to do the infrequent large change thing, then moved to frequent small breakage.
Specific to add-ons: every release has broken some and the XUL depreciation is to some extent to deal with that problem better.
Note that users hate both options proposed in the article passionately, it just seems that break early break often results in fewer users voting with their feet.
I think they aren't a reasonable comparison because they're very young and warned up front that they'd break compatibility several times in the early years.
