This was added via T123153: Do not hardcode dialog widths to avoid cutting strings (ellipsis) in 2016. It does have so many issues:

• It's rare that a dialog title is so long that it appears cut-off. A solution that tries to improve such an edge-case should take care to not introduce new issues. But this one does.
• Users typically don't expect a tooltip on a window title. I believe it's fair to assume that the majority of users running into cut-off titles don't think of hovering them with the mouse.
• It doesn't help users on touch devices.
• It doesn't help screenreader users, even makes their life harder. Screenreaders don't have a problem reading the full title no matter how long it is. When the software is configured to read title attributes (the screenreader users I know do this) the text is read twice.
• It's useless and confusing in all situations where the title fits. I believe it's fair to assume that this is the vast majority of situations.
• Reading the short discussion in T123153 I do have the impression that:
  • Even back in 2016 it was clear this is just a band-aid patch, and probably not even a good one. (Quote: "Let's do that as a start.")
  • It's hard to tell what the reasoning for the tooltip solution was, other than being quick to implement. Nowadays the browser tooltip feature is considered to be inaccessible, see e.g. https://sarahmhigley.com/writing/tooltips-in-wcag-21/.
• The implementation is half-baked. The duplicate tooltip is only set under very specific circumstances. Only when the ….static.title property is used. But:
  • Not all dialogs do this. There are multiple ways to achieve the same, e.g. using a config option or calling this.title.setLabel(). Only some duplicate the title.
  • Many dialogs change the title dynamically. I could not find a single one that makes sure the tooltip is updated accordingly (or removed). Instead the tooltip says something wrong then. This probably qualifies as a bug in the majority of situations.
  • It's entirely undocumented, as far as I can see. Devs using a subclass of the Dialog class aren't aware of this and it's implications. This backs both the "band-aid" argument as well as the argument that this behavior potentially causes bugs in all code using OOjs core.

At this point it's better to ignore and work around this behavior (by not using ….static.title but manually calling ….setLabel()) or revert the patch from 2016.

A proper solution should act only when necessary, i.e. only when the title is actually cut-off. And even then a tooltip might not be the best solution. Instead:

• The font size could be lowered a bit.
• It could wrap to 2 lines.
• The title could start a scroll animation. (Not that I think a distracting animation is a good solution, but it's a solution I have seen in other places.)
• Another truncation algorithm can be used, e.g. one that puts the "…" in the middle instead of the end.
• The tooltip could be shown on click instead of on hover.
• …

Some code already contains manual calls to this.title.setTitle() to work around the bug described above, see e.g. https://gerrit.wikimedia.org/r/700849. This does not scale:

• According to T123153 the only reason the tooltip is there is to repeat the visible title. But the current implementation can't guarantee this. It's incomplete, causing unexpected behavior.
• We can't expect every user of a Dialog subclass to know that calling this.title.setLabel() is not allowed without calling ….setTitle(). This should happen automatically, just as the initial tooltip is created automatically.
• Manually calling ….setTitle() in e.g. VisualEditor means we work around a bug in the wrong codebase.
• Every manual ….setTitle() call hard-codes parts of the current implementation. Changing the implementation in OOjs (e.g. use other tooltips instead of the browser ones, or only show a tooltip when the title is actually truncated) will break such users.