From IRC conversation with @Krinkle earlier today

17:07 <Volker_E> compared Google and Facebook, very mixed approaches, mostly based on px now for nearly everything
17:38 <Krinkle> Yeah, CSS "px" nowadays has a fairly consistent ratio to physical size. And worst case scenario (e.g. someone running 800x600 on a 4K monitor for some reason), it will at least match their expectation relative to everything else.
17:38 <Krinkle> But, that only applies to the top-level.
17:38 <Krinkle> I realise now the question of em is more about code management. relative size management.
[…]
17:40 <Krinkle> My gut would tell me that inheritance is almost always a bad idea. And em would fit with that. Magic indirection, almost never intentional. That feeling of "it will all magically adjust" - I have never seen it happen in a way that was intentional.
17:40 <Krinkle> once upon a time there were browsers that adjusted text-based zoom separately but afaik that's not a thing anymore.
17:41 <Krinkle> So yeah, maybe absolute pixels in code would make things easier to reason about and standardise, especially when the context is uncertain.
17:42 <Krinkle> If I embed an OOUI button somewhere, you probably don't want it to vary by a random <div> that happens to set font-size for some reason. And in the rare case you do, there's probably a "small button" class or some such.

I think being able to resize everything by just increasing the font-size is valuable and convenient. Example use cases:

Bigger buttons

Mostly for call-to-action kind of buttons. Example: https://commons.wikimedia.org/wiki/Special:UploadWizard

The "Select media files to share" is made larger than normal by adding font-size: large; to it.

Bigger icons

Mostly in headings etc. Example: https://en.wikipedia.org/wiki/Special:CreateAccount

(Currently not using OOUI icons, but it probably should.)

@matmarex Those possibilities would largely remain, just in a different way.

In your example of Special:Uploads, font-size would remain relative, so even with only defining font-size: larger and not taking care about padding in a separate selector, the difference would be

With only ems	With padding in px

Not perfect, but acceptable. For this specific issue I'd even recommend providing a “larger” button option out-of-box in the lib.

For icons we could still apply sizing in ems and document where ems are of a necessity/or advantage. To go even further, I haven't seen one good example where the flexibility is used in a convincing way, but several times I've been in conversations with cursing peers on this specific topic, as it's additional complexity which sees very little acceptance or duplication when we look into what most of other Foundation products do.

I'm convinced that changing most of the mentioned values over will bring a relief from a historically-induced dead weight.

In a related story, the flexibility of the library in base font-size mostly remains.

MinervaNeue at 16px before	after

It would be a minimal reduction from 35.69 px to 34px height.

Let's keep in mind, ability to increase button font-size and therefore appearance of the button also remains.
That should even work with nested widgets.

Exemplified on OOUI with new px based values in Chrome with 26px font-size in settings:

Change 514970 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] [DNM] WikimediaUI theme: Use px instead of ems

https://gerrit.wikimedia.org/r/514970

Note, the one very visible difference with the patch is the vertical slight alignment issues in buttons when user chooses a bigger font-size. We could use a line-height equal to the minimum height, but that would once and for all negatively impact the multi-line ability of buttons largely. So I think it's more acceptable to have a button label slightly misaligned from a rather large default font size like 22 on.

In T220671#5257758, @Volker_E wrote:

Note, the one very visible difference with the patch is the vertical slight alignment issues in buttons when user chooses a bigger font-size. We could use a line-height equal to the minimum height, but that would once and for all negatively impact the multi-line ability of buttons largely. So I think it's more acceptable to have a button label slightly misaligned from a rather large default font size like 22 on.

Aligning stuff in CSS is another classic issue. One approach that can be considered is to use flexbox which is intended to simplify the problem and browser support seems quite good. Especially if we are considering cases where very old browsers will get a slightly missaligned UI instead of a completely broken one.

Another benefit of the 'em' approach has been that it nudges users towards a grid, where the smallest unit is 14px, for example without looking up any less constants I know that padding for framed content should be 1em. If we switch to px, no doubt we will see much more inconsistency in margins and paddings.

In T220671#5292590, @Esanders wrote:

Another benefit of the 'em' approach has been that it nudges users towards a grid, where the smallest unit is 14px,

The problem with our current environment in this “logic” is that we've got a 14px “grid” (actually 7px) as on Vector and a 16px grid (8px) on MinervaNeue. A sometimes painful confusion for both, designers and implementors.
When you're designing on mobile and desktop, like just recently on the GrowthExperiments you suddenly have to switch your calculation base in all templates.

That's only a problem if you have to mix your ems with px. If you do everything in ems then everything will just scale for you. Yes the designs will scale slightly between the platforms, but not to a level that causes serious problems.

In my experience, the more problematic aspect of ems is that they are dependent on their container. So reusing a UI element in two different areas or making any changes that affects their container leads to unexpected inconsistencies that are hard to catch.

In T220671#5295333, @Pginer-WMF wrote:

In my experience, the more problematic aspect of ems is that they are dependent on their container. So reusing a UI element in two different areas or making any changes that affects their container leads to unexpected inconsistencies that are hard to catch.

It can cause issues but it's also a feature, per T220671#5113227

In T220671#5292614, @Esanders wrote:

That's only a problem if you have to mix your ems with px. If you do everything in ems then everything will just scale for you. Yes the designs will scale slightly between the platforms, but not to a level that causes serious problems.

And that's exactly among the main reasons that brought us here, as we can't always use 0.5em multipliers due to other issues laid out in T130691.
Hence em sizing often ends up in sub-decimal numbers that are harder to understand, harder to get right and very uncommon in the Web out there making it another hurdle to get into our environment for newcomers.
Nor do devs use ems consistently due to limitations like inheritance or time-budgeting. From current Wikimedia deployed codebase, there's a lean towards px.
See VisualEditor for example:

• https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/VisualEditor/+/refs/heads/master/modules/ve-mw/init/styles/ve.init.mw.DesktopArticleTarget.init-wikimediatheme.css#14
• https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/VisualEditor/+/refs/heads/master/modules/ve-mw/init/styles/ve.init.MWVESwitchConfirmDialog.css#19
• https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/VisualEditor/+/refs/heads/master/modules/ve-mw/ui/styles/dialogs/ve.ui.MWGalleryDialog.css#9
• https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/VisualEditor/+/refs/heads/master/modules/ve-mw/ui/styles/tools/ve.ui.MWEducationPopupTool.css#28

Therefore reducing complexity and limiting them to the absolute necessary minimum appears as preferable solution.

Further examples where our current mix fails:

To the concern of vertical alignment of buttons at higher font sizes:
The default size (16px) stays default

at 20px default size or 125%

Chrome	Firefox

at 24px default user choice or 150%

Again, this is only a minor side-issue from my point of view, as we're not negatively impacting the functionality. In contrast to other websites out there we're enabling the text zoomability on our products.

Change 514970 merged by jenkins-bot:
[oojs/ui@master] WikimediaUI theme: Use px instead of ems

https://gerrit.wikimedia.org/r/514970

As stated in task description, this change shouldn't have any visual impacts, as any former em based derived interface is still relying on unchanged parent's font-size (skin, extension, library, etc.) or root elements font-size (skin).

Change 541905 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] Update OOUI to v0.35.0

https://gerrit.wikimedia.org/r/541905

Change 541905 abandoned by VolkerE:
Update OOUI to v0.35.0

Reason:
for v0.35.1, which is on its way

https://gerrit.wikimedia.org/r/541905