While I'm not the person you commented on I can somewhat provide insight into why it may have happened. In short, the sentiment and statement you made is misplaced and false, and neglects two critical things that are common knowledge at a professional level, which you may not be aware of. I'll elaborate below:
First, customized versions of firefox that have been non-insignificantly patched or may have been rebased into a custom tree or fork. Having a certificate hard-coded, creates by design additional work for anyone not following anything except the mainline tree. From a design perspective its known-brittle and lacking any common resiliency feature normally included in such systems. There's a good chance this was intended, sufficient to treat this as malicious compliance. By those who may maintain repositories, this can be perceived as a resource drain attack on said projects that value privacy but who have limited resources to fix the inevitable failures caused by these design decisions.
Mullvad Browser, or Tor Browsers as examples, albeit they have more resources than some of the other browser projects.
Second, many recent updates have been user hostile by Mozilla. A slew of features supporting bulk data aggregation, while also removing toggles that would frequently disable such features has been growing.
Forcing an update removes user choice and agency which they previously had in older versions, with coercive influence. Most importantly at the professional level, a lot of code changes translates into a lot of bugs, failures, and crashes.
When you have many upstream changes, to control costs you generally keep a local or semi-local repository to manage time cost in support and keeping a foundation you can build upon while staying sane. The software having a kill-switch like this, that's part of your local repository guarantees breakages, and it may not be immediately clear what the problem is (since its hard-coded). Backported security fixes are not uncommon, but the maintainability and time-cost are nullified by a kill-switch. Many view this as a kill switch because its hard-coded. Certificates for security would as a baseline require features for revocation. To my knowledge this isn't possible with these particular certificates.
There's a general rule, the more LOCs you touch, the more likely something is to break, and they've touched quite a lot recently.
Generally speaking, there appears to be quite a lot of effort (which translates into money spent) to embed points of failure within the client, similar to what Google has done in the past with Chrome.