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.
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.
At one of my latest workplaces, there was a system of loosely connected, branching event-driven processing nodes where the events accumulated additional data as they rippled through the system.
In the code and UI, this was represented as "heroes", coming from "guilds", "embarking" on "quests", eventually meeting their "reaper". On their quests, they entered "locations" containing "pickpockets" that pulled things out of (and put things back into) the hero's "inventory".
This cute-but-descriptive vocabulary really helped less technical people grasp how it all fit together -- even if it was a complete lie and gave the wrong picture of how the system worked under the hood.
(In particular, it is a common misconception that the heroes are driving the action by choosing locations to go to, when in fact it is the locations (processing nodes) that pull heroes (event data) along. But that misunderstanding never caused a problem in the four-ish years I worked with the system.)