Although auditing rules have been loosened up in various respects, ultimately whenever code within the FIPS module boundary changes a new validation and certification process is supposed to be kicked off and tracked. For Microsoft itself it's obviously more convenient to manage 1 module rather than 2. But more importantly, many Microsoft customers depend on Windows providing compliant and
certified cryptographic modules; they don't have to worry about it, period, except to keep their Windows installations updated. With built-in Go modules, that now becomes the problem of every individual organization. It's nowhere near as bad as 5+ years ago, when auditors were more strict about only using certified binary modules, which meant you often faced a Sophie's Choice when it came to bug fixes. Today the bar is more that you're using a code base that has been certified (i.e. built some binary that was certified), and when bug fixes are made will quickly be re-certified (in the interim you'll get forbearance). But it's still a greater process and change management burden than when you're just consuming a certified system library from a vendor who takes 100% responsibility for keeping it in a certified state, and which can be updated independently, without having to rebuild all your software.
While rebuilding your fleet of Go apps may be trivial in a technical sense, organizing and tracking deployment across an enterprise is less trivial. Tracking that your nodes are all running updated versions of Windows isn't trivial, either, but much easier.
FIPS is a PITA largely because of the change management burden. But that's precisely one of the biggest gaps in enterprise security. Keeping most of your installations up-to-date is easy; it's the long tail of stragglers and misfits that is the most difficult part. In that light, quibbling about algorithms is almost like bike shedding, though it's difficult to overestimate how much bad crypto is out there (see, e.g., last year's Okta bcrypt issue that is making the rounds again on HN). When people complain about having to use ECDSA P-256 instead Ed25519[1], I want to roll my eyes.
[1] Ed25519 finally became FIPS compliant only last year, there aren't many (any?) certified implementations, and in any event P-256 is just much more widely supported, especially in niches like HSMs, etc.