Tried this in GIMP 2.8.6, 64 bit Windows 7 Home Premium; does create menu element/submenu as you predict, but Windows "wait" wheel spins, then nothing at all. This may be due to fact my CPU is dual-core yet non-hyperthreading (unlike your i3).
Edit 10-09-2013: Egg on my face; I took another look at the script as it appears on GIMP Registry prior to copying; I noticed that form of things seemed proper Python, but then at three or four places there are English spelling errors (e.g., "Creaging" instead of "Creating", "Makeing" instead of "Making"). Since my Windows and GIMP run in English, I corrected those few mis-spellings on a copied text, saved it as .py, and...Yes!! Your wonderful script ran first time, every time! Thank you for this wonderful little gem and timesaver, and I hope this encourages more people to use your script.
I use this GIMP on a three-year-old Acer 5736Z non-hyperthreading 4GB dual core (AMD64/Intel4500) Windows 7 Home Premium 64 bit laptop utilizing off-shelf motherboard Intel Series 4 chipset GPU, always updated to current re MS and having Java, Visual Studio assorted versions relevant parts as other apps require, and .NET Framework 4.5 (all also always updated to current); again, this GIMP was downloaded from portableapps.com; it has 12GB RAM available to it on its USB, HDD usually has at least 400GB free space (virtual) and a paging file of about 8GB. This laptop was capable of running full Autodesk 2012 Maya, currently can run Lightworks 64 bit and Lightzone...but it never in its life has been able to use things like "Hitfilm" effects, i.e., anything that needs CUDA/hyperthreading/large NVIDIA or similar cards...thus why I guessed layers of "Carto" might need to occur all at once ala hyperthreading and didn't work on the Acer.
This GIMP I mention has grown to about 500MB in size due to operative plugins including GMIC and Mathmap; there are a handful of plugins/scripts once tried but also not working in my version so removed. It's interesting to me that compilers mean much to such apps; I also have used Blender from Portableapps, but recent versions haven't been performing well in most cases...they don't do more than ONE version for download of any app at a time (always the last version of an app they portablized), and I've also been chalking up such Blender performance issues to their non-CUDA coding and my lack of advanced CPU, even if Blender.org wasn't mentioning need for it (many today just assume people using their stuff have state-of-the-art equipment.
Maybe Portableapps needs to ensure whoever's compiled a version of an app in their platform has the right stuff to work with newest as well as backward compatabilities, I can't know. But based on your reply, as soon as I can, I will try other downloads of GIMP at least to see if your plugin and others will work for me, too. Thank you!
I'm working with the gimp using an intel atom CPU - and it works fine. And it works on my cellphone, too. So the source code of the program seems still be to be CPU-agnostic. But it might well be that your gimp was compiled by a compiler that translated the source code into commands a modern CPU can do wonders with - and an old CPU lacks.
What also might go wrong is: The gimp is a very big program and it can eat loads of RAM. If no RAM isn't there it will use hard disk space instead. But this might mean that one two processes that should run simultaneously are swapped to the disk every time after having run for 50 milliseconds or similar. Had once the case of an old computer that lacking the adequate amount of RAM did need more than a week to start.
Which system are you working with? Using linux there is top and using windows a process manager (press ctrl+alt+delete to start it) that can help telling what the computer is busy with.