It is, though. As I said, it’s a subtle tradeoff. Inform has to be a good parser for any game, which means considering the work load on the author as well as the player. This is a question that doesn’t come up when implementing a single game-with-parser system.
It’s possible for a Z-machine (or Glulx) game to work around the dictionary size limit by inspecting the input buffer directly. It’s a hack, but the author can do it if they really need to.
I don’t want to come across as a shill for TADS and adv3Lite, but these are the tools I’m using, and so I’m (somewhat) familiar with them.
The adv3Lite library has a clever short form for describing an object, parsed at initialization time, for the author to declare nouns, adjectives, pronouns, and articles. It even attempts to recognize side-cases like mass nouns and prepositions. The full details are here.
The format seems complicated only when the side-cases are highlighted. In practice, I find myself typing strings like so:
'a chair'
'a padded chair'
'a padded chair;comfy comfortable'
'a padded chair;comfy comfortable;recliner'
The internal parser parses the words up to the first semicolon into articles, prepositions, adjectives, and nouns. (It can parse more complicated syntax too, such as 'a pile of rocks'.) The optional list of words after the first semicolon are additional adjectives. After the second, additional nouns.
Also, the phrase before the first semicolon becomes the object’s general name (how it’s referred to in listings, inventory, etc.), hence why you might want to use 'a chair' in one context and 'a padded chair' or 'a chintz chair' in another.
Once you know the format’s shorthand, it becomes second nature to specify vocabulary this way, which is handy when banging out objects in a room.