The main thing I am missing here is an explanation of why I should use this API - what problem it is solving.

I didn't really find that here but I did find some stuff here and especially in the linked demo, and in the spec.

AIUI it goes something like:

• web developers sometimes want to add UI components to their sites that have "close behavior" that is, the component appears and the user can close it when they are done with it. For example, sidebars, popups, dialogs.
• users generally expect to be able to use a particular method to close these components - for example, Escape on devices with keyboards. But this is dependent on the platform: for example, on Android, users expect to use the back button.
• for built-in UI components, like <dialog> and popups, the browser takes care of closing the component when the user performs the appropriate action. This also makes web apps more integrated into the device, closer to native apps.
• but for UI components that the user has built themselves (like a sidebar) it is difficult for the developer to respond to these device-specific close methods. You can't just listen to Esc keypress events, because that won't work on Android.
• so the close watcher abstracts the device-specific close methods, and deliver a close event to the app when the user executes the appropriate one for the platform, so the web app can have this kind of device-integrated UI pattern.

If this is right, we should say something like it.

A close request can be for anything that the user wants to close, like a popover, a sidebar, a dialog

Also if I'm right I'm not sure whether we would use this for built-in components like dialog and popup. Don't they automatically close when the user executes the close method?

Yes dialog (specifically when showModal is used) and popover (specifically when popover="auto") have an internal close watcher, so you don't need to use this API for those elements. However, for anything else you make yourself you would use this API.