As both an active gadget writer (on pl.wikipedia) and a core developer, let me say that while I would *love* to have a somewhat formalized code-review process for gadgets, it is pretty much not possible, and the reason is twofold.
First, code-review is, apart from spotting bugs, about getting the code to adhere to certain formal standards and code conventions. We have lots of such standards and conventions in core, for example, and while almost all of them are useful or (at least not troublesome) to a seasoned developer working in a team of a few dozen people, every single one is also *damned boring* – and if we make writing gadgets not enjoyable, people will stop writing them.
When you're a single person working on a 200-line script, who the hell cares if you use == or ===, or if you use multiple `var` declarations in a function, or if you use `alert()` to notify the user that something went very wrong? In most cases this does not matter, and if the code works, that's all good. Unfortunately writing code for core is largely about petty things like this; if you're a biologist who learned to program for fun and wrote a tool in JS to scratch your own itch, code style matters very little, both for you and for other people who enjoy using your toy.
Second, en.wp might be an exception, but most communities simply don't have enough active people. On pl.wp (ninth largest Wikipedia), I am currently the only active JavaScript person; who do I ask for review? Even if core developers or people from other wikis volunteered, they'd surely not be able to understand the "domain", especially due to the language barrier. And my core experiences say that the slowest part of code-review is getting someone to do it (I have 30+ unreviewed or +1'd patches pending right now).
And as Brad mentioned, informal code review happens; people watch gadgets' pages and look at the changes, non-admins have to ask admins to have their gadget code "merged", admins are generally responsible people anyway, and even *if* something bad does happen (which I feel happens less often than with MW deployments, really), reverting or fixing the change takes one click instead of a multi-hour deployment process.
I really liked what Jon said at the beginning, and what has apparently been lost in the discussions already – "Keep gadgets for experiment, but ensure global gadgets are held to a higher standard of quality and made more visible to a wider audience.". Proper global gadgets still don't exist, but when they finally happen, experienced coders who do this for a living should take them under their wings (to clean up existing code, to check new contributions – but a "post-merge" code-review might still be more appropriate); but local gadgets should stay the safe haven of innovation they are now.