There is a bit more nuance here though. There may be users who trust their old systems but no longer trust the current state of its manufacturer or their binary only updates. Proprietary blobs go against the core freedom as defined by FSF so I can understand why they block by default but IMO they should allow informed users to override. Simply censoring without allowing a user to bypass is not user (or freedom) respecting. The power to choose should be with the user, whom the FSF claims to represent.

Just because some proprietary code exists doesn't mean you should leave the door open for them to add as much extra proprietary code as they wish.

You can regard it as two separate features: one that's needed for the CPU to function, and another that's the door for more code being added. In that perspective it's better to go with preventing additions.

You can't add much to a CPU via microcode. The space of what updates can do is extremely limited, with a limited amount of patch RAM and patch registers. It's designed to fix bugs. You're arguing against fixing bugs in proprietary software you're already running.

So why don't CPU vendor open source their microcode? Secrets... ok, let's use the ones which have no secrets.

Good luck with that...

This is a double edge sword.

If there are issues with what are initially released and you do not patch you do not get those fixes.

So they could add stuff but they definitely will fix stuff. Not updating could be more dangerous then updating.

Intel hardware definitely cannot be trusted. Probably "good enough" for most people, but it's honestly garbage, security wise.

And yet that terrible security situation has approximately nothing to do with the FSF's "no visible blobs" rule. ME could be just as bad running off of ROM, and then it'd meet the FSF's "Respects your Freedom" requirements.