A more plausible explanation is that there's a very strong culture of using Chrome for work stuff at Google, and a general belief that automated tests can replace manual tests. These "oops"es are more likely the result of engineers doing most of their work in Chrome, and not noticing subtle changes in browsers they don't often use.
Couple that with the article's documented case of using a deprecated API from Chrome that's unsupported in FF. That's bias in the design, and that's something that leadership is either not catching, or making a conscious decision on. I'm sure it's couched in some statstic about which monetizable users are impacted or something. But at the end of the day it's an organizational, structural bias.
And that's not to say this is necessarily illegal. I honestly wouldn't know. But I think you made a straw man to attack. The allegation isn't necessarily that there's an organization wide conspiracy of evil Googlers. Just that the organization and culture is designed to benefit Chrome and disadvantage Firefox, and that's happening regularly with user-harming effects.
In many ways, I’d treat this like mandatory banking & investment separations where a cost of being a browser developer should be that you can’t ignore things other shops can. Vimeo could decide not to fix a performance regression affecting Firefox but YouTube should be required to fix it within 60 days, and if they don’t like that they can split it into an independent company which wouldn’t have that constant conflict of interest concern.
However, I don't believe that engineers are intentionally disfavoring Firefox, trying to drive market share down to "run out the clock" or "sabotage" competitors.
For all its dysfunction, Google does tend to hire well-intentioned people - the person being quoted even said as much. There's also a long list of annual trainings that coach people to tread lightly regarding anything that might be perceived as anticompetitive.
It's fair to talk about the craft of engineering and how different processes have different effects. Like I said, I have to be conscientious about what I say, so I'm not going to engage that point. But loaded language like "sabotage" and "run out the clock" suggests a malicious intent that I don't believe exists.
Serious shops have literal walls of devices for automated testing across different browsers and OS stacks, with real-time Quality of Experience metrics streaming back from customer devices - tagged with environment metadata - to detect regressions to the experience on every release.
I find it hard to believe that one of the largest web-native giants in our industry didn't follow those practices as an oversight. I hold engineers at Google in higher regard than that.
It’s silly to assume they didn’t do it on purpose.
You get a bug that a certain feature is crashing Firefox, or slowing it to a crawl. You can't do feature detection, because Firefox reports the relevant features are supported. So you code up a less-efficient behavior that avoids the crash, and only use it for the Firefox user agent.
Months or years later, Firefox improves the problematic behavior, and now performs much better when you switch the User Agent to Chrome and get the efficient path. Nobody at Google is paying active attention to that code anymore, so it remains in that state until someone notices.
The idea of slowing down Firefox based on a User Agent check would be totally crazy to anyone I worked with at Google, and you'd be immediately reported to legal and HR if you tried to get such a thing through code review...