Yes. You are partially right, since IE has been discontinued. But this setting does not affect only the IE itself, but also the legacy software which might still instantiate the legacy web browser, and it is affected by this, and this is also used for various compatibility modes as well. If that setting would not have been used at all in Windows, an update would have been erasing it - but it didn't.
But point taken. I will discuss this with the team to see if it is still of interest to have the IE setting active on scanning.

Fix the problem can be different things, depending on the issue found. I suppose this is a part of Vulnerability scanner (although not specified explicitely, this is the main place where this is analized).

The vulnerability scan looks on on these things: windows updates; application updates (a fixed set of mainstream apps); Wi-Fi; autoplay; weak passwords; hosts file; and the final set being what we call internally IOR (Indicators of risk). This last component analysis focuses on 3 categories: vulnerability, misconfiguration, and human based risk (and classifies the possible results in what the vulnerability scan wizard displays as Operating System security, Browser security, and Network Credentials).

Internet Explorer, while deprecated, is still present on a configuration and legacy level. There are still solutions based on ActiveX controls, download zones, scripting enabled etc. which, while maybe not directly used by the Edge replacement, might be still used by other logic components of the operating system. And remember we are still one of the last, if not the last, solution that still supports Windows 7.

For the Internet Explorer case, what the scanner does is to check how these various flags and settings are configured. If a certain setting is expected to be OFF to be secure, and it is ON (insecure), this is
If, for example, a setting like "Run unsigned ActiveX" is enabled, this is a vulnerability; it is detected, displayed in the wizard, and clicking on the Fix button does, in this case, update the registry value from the vulnerable setting to the secure setting.

"How to fix the problem" would be an interesting proposition, but I think it will be read by a handful of users, not to mention that advising an user to fire up registry editor (or even worse, an elevated command prompt or powershell, run this command - or another, since it might depend on the OS version) is not the vast majority of users would do, and frankly, they should not, because this sort of things is a last resort since one would directly change important or even critical settings by hand. I will ask the team, though.