Item systems don't need to be fast but this thing is a recipe system which will trigger everytime you pick up an item, anyway. Artificial: Yes, something like that would be good, another thing would be that in the case of a pickup event you only need to consider the recipes that use the item.
GC is ok for this in terms of speed since it is O(1) instead of O(n) it would be faster, you could make your own hash table, but I think Griffen got a good idea with big arrays, it still though requires a way to convert the item type to an array index. The problem is how to implement this stuff without adding weight to the requirements, making it use its whole gamecache file would be a little too much. Also you'd have to be careful not to make this cause an item type limit. -you could use one of many libraries out there that do hashing-
it wouldn't scale well with things like 50 recipes in the whole system, it seems like a big value but there isn't too much reason to use one of these systems if you don't plan having plenty of recipes in your map.
The optimization would not be a requirement for approval, Something I don't like too much is how it forces the guy to use plain integers for the recipes thus losing some type safety and convenience around, you could actually make recipes creatable as just recipe.create() and what not, you can also make the functions return a recipe and make the recipe struct public and have some read only fields that could be helpful for the guy using your system. Even if you don't add these things, make the functions take and return recipe, it will make life easier when jasshelper gets type safety and that stuff.