A lot of browser customizations are truly trivial, just adding some function that can be expressed regardless of the page you are viewing. Not all such hacks need full access to the underlying browser and hence don’t need to be exposed to the full panoply of inevitable security problems.
JetPack always struck me as a decent solution for these circumstances. I never thought that replacing Firefox’s existing extension API was a priority goal of the project, even though that is clearly what some are thinking lately. The very reasons the anonymous poster finds this objectionable, I see as very sane reasons JetPack is not meant to replace extensions. At least not until its own API is able to not only make up the difference but to do so in a way that is consistent with the primary goal of simplicity and safety espoused by the project.
Thankfully, Glyn Moody tweeted a clarification from Asa Dotzler. Reading through the original post by the JetPack project lead, I suppose I understand the source of the confusion. However, it also doesn’t seem that hard to find a clear answer on the question of JetPack vs. extensions. The quotes in Asa’s post are pretty consistent with what I have assumed all along, that some day, JetPack may mature to the point where it makes sense to replace Extensions but that is nowhere in the near term roadmap. The act of speculating on such a far flung future seems to have short circuited the logic circuits of some readers, leading to the confused and confusing post on Slashdot.
My other pet theory about JetPack is that in as far as it sticks to browser agnostic standards, a very interesting project would be to port it to other browsers as a way for developers of certain classes of browser hacks to be able to share those even more widely than the not inconsiderable user base of Firefox. Don’t mistake me, I am not claiming this an explicit goal of the project, just something that occurs to me personally as an interesting thought experiment.