I would say that adding the booleans to identify broad-scale when they are appropriate to consider (hostile action, city augmentation, unit augmentation...) and then within each of those allowing a python callback might be a nice compromise. Then you can still hardcode, but do it in python, and avoid SOME of the cost. But this approach would be more costly than a single general python override if many spells have multiple booleans flagged (then you have them making 2 or 3 calls for that spell instead of just 1).
I haven't looked at Sephi's code at all yet (so I am kinda sticking my nose where it doesn't belong by responding, sorry. I'm annoying sometimes
), but I know that some spells could use fundamental changes to make them more AI friendly, by which I mostly mean bringing them into the DLL instead of python. Vitalize/Genesis is one example where a function could be written to determine the "next best plot type" for any given plot (seek to upgrade food, then production, then Commerce). This brings it generalized into the DLL, automatically includes newly added terrain types like Marsh, and accounts for unique yields like the Illian Snow. Plus by having made it a DLL process, you can make a simple check in ::chooseSpell to see if there is a tile within a limited range which is not "maxed out" for tile type, and to travel there and upgrade it (you could even go to making separate spells for upgrading each of the three tile yields individually so you can aim for better production instead of better food as a final goal, and store the total "shift" from the base tile separate from what the tile actually is originally so that you can make a spell capable of only upgrading a tile once (can take snow->tundra, but cannot continue to take the tundra->plains) and another capable of upgrading an unlimited number of times.
But of course, those recommendations require more time and consideration, and potentially alter features of the game semi-heavily
You could try creating a python override for this function with a Callback control defined in the XML so it is easily disabled, then run a profiler with it on/off and see just how bad the cost really is. I would imagine it isn't actually bad enough to be significant since AI considers spells once per turn per unit. If it is bad, you could use a cache system to identify if a unit is capable of casting any spells at all and disable the callback for any unit incapable of casting (though again this is a more complicated approach which could take some time to develop)