A little knowledge is a terrible thing....
I just had a look at the list of plugins in my Firefox install.
Adobe Acrobat - I was never asked for permission.
Google Earth Plugin - I don't remember being asked for permission, but it's possible that I was.
Google Update - definitely I wasn't asked, because I would have said no.
Java Development Toolkit - definitely wasn't asked.
Java Platform SE 6 - definitely wasn't asked.
Novell iPrint plugin - definitely wasn't asked.
I'm pretty sure that I don't need the Google plugins - especially the Updater, and I know that I don't need the Adobe plugin, but at least one of the java plugins makes sense - after all, the only reason that I installed Java at all was because I need it for some web based apps (thankfully a vanishingly small subset, maybe I should uninstall it completely and see if I can get away without using it now).
So it's pretty obvious that Microsoft didn't do anything "devious or underhand" with their deployment of the .Net framework plugin - it's standard industry practice to configure the necessary plugins in the users browsers, so that the browser will work as a platform for whatever it is that the plugin supports. By consenting to the installation of the parent application, you consent to the installation of the necessary enabling plugins.
The only thing that is clear from this whole fiasco is that Mozilla's blocking "feature" is fundamentally broken - it disabled the plugin on systems that had already been patched against the vulnerability. The difficulty of managing Firefox in a corporate environment is already a big problem - this sort of behaviour is not likely to win them many friends in that space.