I can't see any logic to revert it.
Windows implementation behavior will be inconsistent with Other implementations now.
The issue mentioned in #1982 was caused by wrong configuration, not the patch.
He must sign his certificate correctly to establish TLS connections, not by ignoring certificate issues

What mentioned at #1982 is that PR #1893 causes the windows clients not trusting LetsEncrypt certs. Thus we revert it to the original way. The PR has side effects.

By calling loadSelfCertPool, it overrides the system certs on windows. That's why raymond introduced the DisableSystemRoot config.

Maybe there are better ways handling the situation, but simply ignore the DisableSystemRoot mechanism surely not.

By investigating deeper on the cert loading code (sorry, my first time digging into them), I found that on windows, x509.SystemCertPool() is not available.

I agreed what you said, weather DisableSystemRoot on or off, core should load the custom certs, but on windows you can not combine system certs and custom certs easily.

The inconsistency of behavior is an OS level problem, I believe. I also see that their's work-arounds getting the system certs on win, but it seems requiring administrator permissions, and it's complicated, I don't like it.