With ... pending, we should consider to apply opinionated rule to set a standard for MediaWiki skins deployed by Wikimedia Foundation and possibly core too.

Vast majority (I'm not aware of any exception myself) of rendering engines default to 16px as standard text size for HTML content.
By setting

html {
  font-size: 62.5%;
}

the calculation based for rem values in any child element is the equivalent of 1rem = 10px.

So setting for example

.mw-body h1, 
.mw-body-content h1 {
    font-size: 2.88rem;
}

would apply the same rendering as current font-size: 1.8em; or 28.8px in Vector. See https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/622742/1/resources/skins.vector.styles/skin.less for an example.
Additionally we are able to set per-skin base font sizes.
In Vector (legacy & modern), MinervaNeue, Timeless,

body {
  font-size: 1.6em;
}
// Note, the 14px setting in Vector happens on `.mw-body-content` with `font-size: 0.875em` currently.

rule leaves existing em based products, gadgets and user styles rendered unchanged.
Monobook is not render-affected at all, as it uses keywords for its font size.

Benefits

For new products in MW 1.36+, implementors have the ability to rely on a clear approach to implement designs without worrying about confusing inheritance/calculation or risking accessibility impacts
Alongside the variables implementation brought forward in Icf86c930a3b5524254bb549624737d3b9dccb032 the long-term goal should be to provide sizing variables for all different font size based skins.

• Persist / possibly improve user experience by enabling skin interfaces a full use of rem units, making them fully text zoomable by users with accessibility needs and do away with pixel based text and image sizing
• Simplify design–development handover by replacing close to imcomprehensible em based sizing,
  • Latter has not been fully applied across core. So we see a mix of percentage values for font-size and em values, making it harder to quickly orient in code thanks to this and the cascaded inheritance of em values.
  • It has led to mixture of unit based sizing (px and em), see for example
    • https://gerrit.wikimedia.org/g/mediawiki/core/+/203cf57d0476a865c8028754ef1db7f09a6afaf6/resources/src/mediawiki.rcfilters/styles/mw.rcfilters.less
    • https://gerrit.wikimedia.org/r/c/mediawiki/extensions/RevisionSlider/+/370828/2/modules/ext.RevisionSlider.modern.css

Risk

With an extension only written in rem based sizes, it might not scale with the surrounding skin. It needs to be specifically optimized for each skin.
One way out is the variables approach described above. Another one would be to increase Vector base size to 16px, which has been discussed initially as part of Desktop Improvements project, but is no priority right now. Timeless would remain acceptable with it's 15px size, MinervaNeue works and Monobook would be the only skin to care about.

We're might set a slight design expectation, if devs are not given easy ways to overwrite the size values for a 16px base.

Acceptance

Browsers, which don't support rem would fall back to browser default, so content and interaction would remain acceptable.

Former work

Wikimedia-Portals has taken exact same approach a few years ago and not received reports of rendering issues AFAIAO