Not the language implementation per se, but the underlying hooks that allow it to do its job. For some reason, certain programs fail to respond to Applescript correctly, so scripts like the following don't work properly (and worse, the problem is sporadic):
tell application "Mnemosyne"
Fine, maybe the Python wrapper for Mnemosyne is a bit dodge. But why should it matter?
In Windows there are free third party scripting/automation languages like AutoHotKey and AutoItScript. I've never had a problem bringing an application window into focus with them - why would you? Perhaps Applescript's hooks are at a higher level, while those of AutoIt etc operate on a low level Windows message scheme: instead of applications responding (or ignoring, or bolloxing up) Applescript requests, they simply receive normal window/GUI events, just like when a user is manually clicking and typing.
These Windows automation/scripting languages "just work" - you can assume that a window is just a window and if you can activate one by clicking or alt-tabbing to it, you can activate it via a script - and the syntax is simple and intuitive for most programmers (although AHK's is a bit ugly IIRC).
If they can do that, surely Apple can do much better than Applescript.
Addendum: It seems that you can't even move the mouse from Applescript, without installing extra 3rd party software. Boo-urns!
Addendum 2: Well, it's not giving me error -9874 anymore when trying to activate the window. Also it's become apparent that when activating the Mnemosyne window with a modal dialog open (the "Add cards" window), focus will be on the application's main window, unless the mouse cursor is hovering over the main window. This happens when you manually cmd-tab to the application. Very odd - perhaps the GUI event loop isn't processed properly until the mouse cursor is moved over the main window? Ah well. The rest of my diatribe stands (or crouches) though - I still dislike Applescript in more ways than one.