I'm going to argue against it based on its ambiguity. Just reading this thread illustrates the problem clearly. In the old days of simple, standalone applications and libraries on a single machine, the obligations of the recipient of the source code was clear: your own code must also be GPL compatibile. With this new model of some of the code existing on the server and some on the client, and the GPL's use of the term "derivative work," it's very unclear to the average programmer what his or her obligations under the license are. Ultimately you as the copyright holder have to enforce your license, and the ambiguity in the meaning of the license, your motivation for choosing the license, and your intentions make things muddled.
If you are simply looking for a "copyleft" license in which people must contribute changes to Meteor back, that's fine, but the LGPL or MPL are probably better license choices.
If you want to ensure that your project is only used for open source applications with case-by-case commercial licensing exceptions, that's fine, but the AGPL is a better license choice.