Yes, this is a fascinating part of language design, and there are many ways to think about it.
Personally, I am very fond of the nitty-gritty details of low-level optimization, but I don’t think it belongs at the story level. When in “author mode”, I want to focus on characters, plot, and scenes, as well as robustness, puzzles, geography, hints, synonyms, and responses. Getting bogged down in bitfields would be a distraction.
Ideally I want a high-level language that can be converted into efficient low-level code, using all kinds of clever optimization trickery in the compiler. That doesn’t work unless the language is designed with such optimizations in mind, but that is the case with Dialog. In my example above, ‘(bold emphasis)’ compiles down to a single bit of memory. I don’t see how the people who “strive for compactness to the extreme” could do any better than that.
Meanwhile, there’s another danger when you begin to expose too much detail at a high level: It becomes more difficult to optimize the code automatically. If, for instance, you allow the story author to specify numeric constants for the compass directions, so they can be stored in four bits, then you might inadvertently prevent the compiler from picking a two-bit encoding for stories that only use north, south, up, and out.
Now, as it happens, the current Dialog compiler doesn’t perform that particular optimization. And, in fairness, there are aspects of the language where I’ve valued versatility over compactness. But as a general rule of thumb, high-level code tends to be more amenable to automated analysis and optimization.
Dialog predicates turn into executable code, z-machine object flags, global registers, bits, linked lists, arrays, word tables stored inside object properties, etc. etc. depending on how they are accessed from the rest of the program. The author shouldn’t have to bother with it, and shouldn’t be allowed to meddle with it, getting in the way of the optimizer.
Bitfield packing is no panacea. You bring up z-machine text encoding as an example. That happens to be a very inefficient solution; a Huffman code would fare way better, and would certainly fit inside the memory of an 8-bit system, while improving loading times due to the increased compression ratio. But, despite its flaws, I think z-machine text encoding is a good example of a nicely designed optimization, precisely because it stays out of the way of the author, who is free to focus on more important things.