Is your contention here that there's somehow a human male with two Ethernet ports that is manipulating HTTPS traffic and I'm just too "lazy" to admit that?
1. I landed this fix because there was a policy that did not work properly. We could instead document that the URLBlocklist policy works for every scheme but one, or we could fix it. Fixing it makes more sense.
2. This policy only can be set on managed machines.
3. This policy, in isolation, is trivially circumvented. Managed environments block many things, including many of the proposed circumventions here.
4. I've built one of the world's most popular tools for viewing and modifying web traffic. The narrative that this feature has broad implications for anything is absurd.
It certainly appears to be monitoring the entry of passwords into Facebook, but given the stated purpose of the extension ("Record activities undertaken in the content area for later playback") it's not clear to me that this is the same as "stealing". We'd need to see code that shows the recorded content being exfiltrated to somewhere else, which should be pretty obvious by watching network traffic and or doing a full review of the code.
Many "irrational" decisions are related to interactions with anti-bot/anti-fraud logic.
I worked on IE in the days when there were many crazy conspiracy theories about silverlight and IE collaborating to ruin the open web. This sounds similar.