Or said plugins don't even exist (I mean, same code, same author) and the problem never has a chance to manifest itself in Chrome. In my experience plugin management, or lack thereof, by ignorant users is one big problem compounded by a-hole companies installing plugins that have major performance ramifications (not of the positive kind) without even asking -- "Skype anyone?". Then again, some people don't know any better so it goes back to the ignorant part.
Yes, Firefox did fall behind the curve but that was with the 3.6.x branch. I don't find arguments of "Chrome is faster" to hold up to scrutiny, just do a search on the topic and be objective about what's being divulged.
And if you ever find yourself tethering, Firefox for many years has been the only major browser that supported HTTP pipelining, something that's been part of the HTTP/1.1 specification since 1999... yet Chrome just got or is just getting around to it (I knew it was recently added in the Chromium channel). While I applaud Google with the SPDY extensions, the HTTP servers you speak to with Chrome have to explicitly support the SPDY extensions, i.e. there's still a LOT of web servers out there that do not do SPDY. HTTP/Pipelining on the other hand has been in place for forever and it is not a question of web server operators have to update their existing web servers for end users to benefit. If you are on a higher latency connection, HTTP/Pipelining can make a *BIG* difference.
Finally, if you use Akamai (Content Distribution Network) to delivery of web content to your customers, Akamai funnels traffic to your web servers via HTTP/Pipelining for performance gains which cannot be classified as "minor". Our TCP connection count dropped to 1/10th of what it used to be. I've been using HTTP/Pipelining in Firefox since 2004.