Title says that using a catch all domain (whatever that is) is a mistake, but the bulk of the article about it being a mistake to use the other party's company name as the local part of a throwaway e-mail address which you use for communicating with that party. There is nothing about the catch all aspect being a mistake. You don't have to give a Hilton hotel an address like hilton@example.com; it could be bob-2022-05@example.com, right?
I use a throwaway e-mail system whose generated addresses look like this: 539-343-1293@example.com. The dashes can be replaced by underscores or periods: all are recognized, but not mixtures of them: basically three versions of the every alias is installed. (Why? I ran into a situation where I had to enter my e-mail address into a point-of-sale system that didn't accept dashes.)
There is no "catch all" mechanism at play. Each address is explicitly created, using a web-UI application that I wrote. The moment you create it, it goes live, as a local alias recognized by the mail server.
Each such address is associated with its creation date, and a memo field. If the memo field contains URL's, they get rendered into navigable form. They are editable. The memo field is what tells me who/what the address is associated with. I have a regex search box to filter the entries (quite a lot have accumulated).
The UI is like Web 1.5: you can checkbox these items and do bulk operations on them, like bulk delete, move to top, move to bottom and such.
When I delete an address, it immediately stops working. THAT is why "catch all" would be a bad idea; if you have a rule which routes any nonexistent local part to your inbox then you don't have any easy way to turn off an address which is being abused, other than going into the mail server rules and writing a rule to reject that address. That's not a fun UX, compared to a nice throwaway address management dashboard.
This system is called TAMARIND: Throw Away Mail Alias Randomization Is Not Defeatable. :) :)