Change 276966 had a related patch set uploaded (by Ajayrahulp):
Convert Special:WhatLinksHere from XML form to OOUI form

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

Change 276966 merged by jenkins-bot:
Convert Special:WhatLinksHere from XML form to OOUI form

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

Did anyone test this ?

Two actionable (and hopefully doable) suggestions:

• The "Namespace" and "Invert selection" fields should be on the same line (and behave like a single field).
  • Something I had in mind for a while was a 'namespacemultiselect' field type in HTMLForm, that would display these two fields (plus an "Include associated namespace" one, optionally) and return an array of namespace ids as its data (a bit like HTMLMultiSelectField). Please note that this is not a polished idea and I never tried implementing it :D
  • I did, however, implement MediaWiki\Widget\ComplexNamespaceInputWidget for the OOUI version. It was briefly used on Watchlist (before that OOUI conversion was reverted too, T99256).
• The "Hide blah" checkboxes should also be on the same line and behave like a single field.
  • You can probably use 'multiselect' field type easily here, for a start.
  • We had some other OOUI HTMLForm special page which used a little bit of custom CSS to display similar checkboxes inline, I can't remember which one now.

Quick mockup (edit of the screenshot above):

Needs design team's eyes obviously...

In T135773#2311312, @Dereckson wrote:

@Ajayrahul We've a little issue reverting the localisation of your code: your repurposed messages to give them a new meaning.
This choice makes it's not straighforward to revert: we need to track on TranslateWiki translations update, revert them, prepare a change.
When you change the meaning of an element interface, please create a new message instead of amend existing ones.

In T117754#2311012, @matmarex wrote:

Quick mockup (edit of the screenshot above):

Better than the reverted stuff, but still so much unnecessarily space consuming.
Can't the original layout be kept as much as possible?
Why are labels above controls?
Why is ns selector x-times wider than the widest item in it?
Etc...

Even if I might repeat myself. To @Danny_B's points above:

Why are labels above controls?

Because there's lesser cognitive workload when labels are above controls. People are quicker when fulfilling their tasks on forms with labels above fields. See for example https://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php

Why is ns selector x-times wider than the widest item in it?

What is the problem with this?

Please see also T191868: OOUI in HTMLForm on Special:Pages – evaluate collapsible main forms