Note that by "plugins", the author seems to mean what Firefox calls "extensions" and I think IE calles "add-ons" - not third-party libraries for rendering new content-types within the browser, but code living in the browser that can modify page content automatically.
The venerable Netscape plug-in API is about as browser-agnostic as one can get; I don't think there's a modern GUI browser that doesn't support it, except perhaps Amaya or something.
Actually, he seems to be referring mainly to userscripts, which are a sort of step down from extensions. Extensions typically add to the browser GUI and make only minor adjustments to the DOM, whereas userscripts operate entirely on the DOM and are limited in interaction with the containing browser.
At least, this is my impression. The line gets fuzzier all the time, so feel free to disagree.
The userscript approach would lend itself better to cross-browser compatibility, in addition to being a relevant platform in the era of HTML-JavaScript apps.
Above and beyond the fact that your browser will throw certificate errors every time you hit an SSL site, there is a really easy, really bad failure mode where scripts are injected based on user content delivered over insecure links, into connections to your bank. You might as well just not use SSL if you'll accept that risk.
Yeah, I know you can't do it over HTTPS -- with HTTPS over a proxy, all the proxy can know is the hostname. Such an extension system would be HTTP-only, but I don't think it'd therefore be useless.
The venerable Netscape plug-in API is about as browser-agnostic as one can get; I don't think there's a modern GUI browser that doesn't support it, except perhaps Amaya or something.