MicrosoftHotCakeX - If you have another mechanism for managing the endpoint, then you don't need to include this change in your security policy. If you're OK interactively logging on to each non-joined endpoint to perform administrative tasks, you don't need to include it. Security can involve tradeoffs and secure/insecure isn't always binary. Endpoints that cannot be administered can't be considered entirely secure either. Also, see this old blog post for another example: Remote Use of Local Accounts: LAPS Changes Everything - Microsoft Community Hub
Also note that these security baselines should be considered as foundations or blueprints -- they aren't a complete end-to-end security picture, and deviations can be made when ramifications are properly understood; and they are built only on what can be configured through domain or local GPO. Baselines can't check for "insecure administration method[s]."
Finally, I had to take a closer look at the GPOs, and you seem to be interpreting them incorrectly. All the downloadable GPOs in the SCT enforce the secure setting, "Enabled" (which is DWORD 0), and they have in every baseline since Rick and I added that setting to the custom "MS Security Guide" ADMX for the Windows 8.1 and WS2012R2 baselines ten years ago. One has to run a separate, custom script to change it to the less-secure "Disabled" state (DWORD 1).
