I'm not posting this to be argumentative, but the question is valid, if somewhat vague... and the 2 "answers" posted so far read like opinions (vs definitive answers).
The limiting factor will be the db backend, yes?
The "count" column of the categories table is indexed.
The script offers no "advanced" filter-by-category search, so I wouldn't expect the presence of "quite a lot" of categories to introduce a functional performance impact.
===============
In the absence of subcategories, and without resorting to tags (jumbled, incomplete tagcloud navigation) I can think of valid use cases begging LOTS of categories.
For instance, users of a "birdwatching" or "botanical fieldguide" site might appreciate having Q's categorized into narrow Genus_species categories. That way, they're not forced into searching, searching, searching (and OMG the likelihood of typos!)... and they might wish to subscribe/follow to these narrow categories (vs drowning in too-frequent notifications, if the site employed fewer/broader categories).
Also, I kinda expect that with narrower (more fine-grained) categories... participants might be more enthusiastic about "adopting" a category, to serve as its subject matter expert.
