Hardening WMI: Any security benefit to changing Impersonation level & separately, setting 'Winmgmt Standalonehost?'

Question #1 Does changing the Default Impersonation Level in WMI to "anonymous" or "identify" help mitigate against WMI exploitation, implants, and persistent threats on a local machine? If so, please explain why… and also potential unintended problems that could arise with those settings, if any at all, thanks.

WMI scripts accessing remote computers using anonamous or identify will generally fail. In fact, most scripts run on the local computer using one of these two settings will also fail.

This is changed at the registry key, default is 3, (Impersonate)

    [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWbemScripting]
"Default Impersonation Level"=dword:00000001

These are the different webm impersonation levels

wbemImpersonationLevelAnonymous
1
    Moniker: Anonymous
Hides the credentials of the caller. Calls to WMI may fail with this impersonation level.
wbemImpersonationLevelIdentify
2
    Moniker: Identify
Allows objects to query the credentials of the caller. Calls to WMI may fail with this impersonation level.
wbemImpersonationLevelImpersonate
3
    Moniker: Impersonate
Allows objects to use the credentials of the caller. This is the recommended impersonation level for Scripting API for WMI calls.
wbemImpersonationLevelDelegate
4
    Moniker: Delegate
Allows objects to permit other objects to use the credentials of the caller. This impersonation will work with Scripting API for WMI calls but may constitute an unnecessary security risk.

Question #2 A standalone question. Any security benefit to winmgmt operating outside of shared svchost processes via the command

winmgmt /standalonehost ?

As for security, yes, it is useful for changing wbem Authentication levels, which is changed by the command winmgmt /standalonehost [#] but does setting winmgmt as a standalone host have any security benefit on its own, ex winmgmt /standalonehost? For example, does a standalone host mitigate against attacks upon shared processes in svchost?

Another example. Group policy Svchost.exe mitigations add ACG-CIG exploit-protection enforcement and other process mitigation code integrity policies to svchost procsses. My question is does running WMI as a standalone or shared host result in any security impact with this policy enabled?

Just for reference, I will include Webm Authentication levels

WbemAuthenticationLevelDefault
0
    Moniker: Default
WMI uses the default Windows authentication setting. This is the recommended setting that allows WMI to negotiate to the level required by the server returning data. However, if the namespace requires encryption, use WbemAuthenticationLevelPktPrivacy.
WbemAuthenticationLevelNone
1
    Moniker: None
Uses no authentication.
WbemAuthenticationLevelConnect
2
    Moniker: Connect
Authenticates the credentials of the client only when the client establishes a relationship with the server.
WbemAuthenticationLevelCall
3
    Call
Authenticates only at the beginning of each call when the server receives the request.
WbemAuthenticationLevelPkt
4
    Moniker: Pkt
Authenticates that all data received is from the expected client.
WbemAuthenticationLevelPktIntegrity
5
    Moniker: PktIntegrity
Authenticates and verifies that none of the data transferred between client and server has been modified.
WbemAuthenticationLevelPktPrivacy
6
    Moniker: PktPrivacy
Authenticates all previous impersonation levels and encrypts the argument value of each remote procedure call. Use this setting if the namespace to which you are connecting requires an encrypted connection.