He's referring to the fact that if someone were to give, for example, 1000 prizes over time, with the text for those prizes being 40 characters long on average, then your variable would be 40,000 characters... which mIRC can't handle. Also, if the prizes include a comma and your tokens use commas as separators, it would give incorrect results. In addition, $addtok() does not allow duplicate tokens. I'm sure there will be duplicate prizes, so that would also give invalid results.
Basically, don't use $addtok() unless you can be certain that there will never be legitimate duplicates and that the tokens will not contain the same character that is used as a separator. In this instance, you can't guarantee either.
As for hash tables... they are useful. However, they are most useful with data that is accessed often. I doubt prize counts are listed very often, so hash tables don't offer much benefit over other formats. In general, hash tables are best for large amounts of data that is accessed often, variables for small amounts of data that is accessed often or not often (either one), and text/INI/etc files for large amounts of data that is rarely accessed. And "often" would be at least once every 5 minutes, though that's not really all that often. Really, you'd be looking at data accessed more than once a minute to really be considered "often."
Hash tables can be used for rarely accessed data, but are not necessarily the best option. For this situation, INI is the better option as long as the 64k limit is gone. If there is still a limit, then hash tables or text files are about equally good. You just don't want to try and put many items into a single variable or hash table item, and you don't want to save/load INI format if there is a limit. And definitely don't use $addtok().
