It's Blink that has incorrect behavior here. This is a known bug: see https://bugs.chromium.org/p/chromium/issues/detail?id=1172623.
The spec says that when
auto (the initial value, as here), the zero position from which
text-underline-offset is measured is the alphabetic baseline. So
text-underline-offset: 0 puts the line exactly at the baseline, which means it touches the glyphs, and (unless
text-decoration-skip-ink: none is used), it'll be interrupted wherever the glyph ink occurs.
I don't really know why the site is messing with
text-underline-offset here at all, but adding
text-underline-position: from-font would probably get them closer to what they wanted. But given this CSS, Gecko's behavior is exactly per spec, and Blink is wrong.
Note that in Safari, too, the underline appears exactly at the baseline of the text. (It doesn't have the skip-ink gaps, but that's because the site also uses the non-standard
-webkit-text-decoration-skip: objects to override this; removing that results in Firefox-like rendering.)