1. Probably easier for students to start a new world when testing a new program. I assume there are some commands they can type into the Bukkit interface to start a new world, but it's really easy and familiar for them in Minecraft. I remember from my students' screens that their worlds would get all cluttered with structures generated by their code and they'd need new superflat worlds for testing new code quite often. I would routinely tell kids "Start a new superflat world" when they developing a new bit of code.
2. No need to start a separate server app each session.
3. Much faster getBlock*() performance.
4. The "/py script" Minecraft command supported by RJM is a handy way to start scripts (and include commandline arguments as needed). This makes scripts feel more seamlessly integrated into the Minecraft environment. Once you write a script, you no longer need IDLE or a commandline to start the script. And you can even start the script from a command block. Basically, with the "/py script" command, the kids can feel like they're extending Minecraft.
5. The "/py script" command together with my updated mcpi/*.py scripts is designed to work particularly well in multiuser contexts. For instance, if one kid opens their world to LAN, then other kids can try out that kid's scripts with "/py script". Moreover, there is magic behind the scenes that makes player.*() commands in the script work with each player correctly with no change to the script code. So, for instance, a kid can make a script that launches a missile in whatever direction they are facing. Another kid can connect and use the same script and they can have a battle.
6. world.spawnEntity() command allows one to do things that can't be done with AIM. For instance, you can add an object to the user's inventory, or spawn and control a monster.
7. Most scripts (i.e., scripts that don't use mc.getHeight()) Just Work in the Nether and the End as well.
8. For those students who are used to installing mods, installing RJM at home might be easier. For other students, installing AIM at home might be easier.
9. Read-only protected mode. A buggy or ill-advised script can really mess up a world that you've been designing. (Most of the scripts we were doing were scripts that programmatically generated different structures rather than implemented games.) You can set the mod in read-only mode, and while you'll be able to see the blocks that the script would draw, the actual results aren't saved to the world. (It's kind of hard to explain...) So you can test and debug your code to draw, say, a giant Death Star without messing up your world, and then go and turn off the read-only mode. This is probably not all that useful given that you can also easily start up a scratch world.