I think there could be a difference here: you're already familiar with the domain brew operates in.
The system I'm speaking of were extensively used and configured by people who had no prior experience with event-driven, branching logic, nor any familiarity with the terms involved.
You can still argue it would have been more efficient to teach them that domain first, then teach them this particular system for it. Maybe. I'm saying as far as I can tell, there was no drawback to the cutesy terminology for the intended users (nor for developers other than in isolated cases) and it seems to me they learned quicker with that framing than without it.
I'm not sure assuming people are familiar with the process of alchohol brewing is any better.
I agree -- that's exactly what I was saying. The target audience of brew is more likely to be familiar with package management than alcohol brewing, so the choice of terminology was poor. On the other hand, the target audience of the system I was discussing is more likely to be familiar with a fantasy-like narrative than an event loop, so the choice of terminology was beneficial.
You write software formulas (packaging scripts) into bottles (binary packages) in your Cellar (installed packages directory). Some software, such as GUI applications, uses casks, because casks are a different type of container. If you want a new source of packages, you add a tap.
I would take packages, packagjjt scripts, package repository, binary packages and GUI packages any day over brew's attempt at cutesy terminology.