It does get rid of quite a bit of boilerplate code, and re-writing and testing that sort of thing all the time is a hassle as well as error-prone.

In my experience, anytime we can cheaply automate error detection, that tends to be a leveraged productivity win.  This is particularly true in the case of complex projects with more than a few developers (like ours!)

While I'd love to use Google Closure Compiler, I spiked with it a bunch, and for whatever reasons, it was incredibly painful to make work, and I never got it totally working, even after a bunch of hours of hacking.  Perhaps if we were using a standard module format, it might do better, but who knows.  I'm still hopeful that someday we can leverage JSDoc annotations since there's a fair bit of tooling (IDEs, among other things) that can take advantage of them, and we already have a bunch.  The most likely thing I found was @jetienne's debug.js, but that part of it doesn't look nearly mature enough just yet.  Writing our own would be plenty of work.

There's a bunch of other JS type checking libraries that we could use directly, but they have not-very-nice syntaxes, IMO, and need to be invoked explicitly, and don't seem to be super widely used.

So all things considered, I quite like the fact that this is focussed (a solution for one specific problem that we have), and I'd suggest we do move this forward.