If they cared and their slowdowns were simply related to addons, they could always sample the overhead of said addons and show a warning. My moderate use of addons in FF didn't feel too aggressive, but then again I'm not in the clique with dozens of open windows. There were times of fast/slowness in FF. It was never bad enough to chase me off the platform, but to say the slow ess was simply saddled on addons is probably disingenuous.
It's not that the add-ons were slow, it's that the architecture built to support those add-ons made the browser as a whole inherently slow. Everything was quite siloed, and required a series of dynamic dispatches to accomplish anything. This allowed extensions to easily change lots of core functionality, but also meant that the entire Firefox codebase had become a public API, and practically any change made would break something.
The slowness wasn't caused (just) by slow addons. As I remember it, Firefox was unable to move to a multi-process architecture as long as old extensions were supported.
My recollection was that they had some multi-process things, though the problem was that they had to keep breaking extensions as they added more and more. I believe multi-process NPAPI plugins was somewhere around 3.6 or 4? (Of course, 4 took forever to ship too… that was great for extensions though, because it meant no API breakage during that time.)
It's not that the addons were slow. It's that the architecture in Firefox that was needed to support the addons was slow - even if there were no addons in use.
