I have encountered both cases for z-tables: a few generic ones vs. multiple process-specific/module-oriented tables.
Generic z-tables are nice and convenient to use, but there can be some disadvantages.
When you use generic z-tables, nobody is the 'owner', so maintenance, understanding the logic, review, cleanup, proper documentation can become a challenge (I have seen such z-customizing tables used by several teams with tens of thousands entries). I am not sure about the complexity of restricting maintenance access between departments, I think that it could be tricky sometimes, especially if you use external resources.
With multiple multiple process-specific/module-oriented tables you have the risk of duplicating similar things in several small tables, so probably it is up to the solution architects to review and challenge new z-table creation, so that things don't spin out of control.
Another approach, which I have seen, is using parameters/selection options maintained in transaction STVARV for custom reports. Maybe for some high-level/global stuff it can be useful (if you don't have too many entries and if you can establish control on who/when/why manages what). There must be a good reason why this is not a very popular and common approach, it could be because z-tables give more flexibility and it is easier to come up with good logic compared to TVARVC, or something else.
In all cases - if you get one hundred of possible values for a specific process (and several others to combine with), then it seems to me that either the rules are too complex (then it is a good idea to discuss with the business to standardize and streamline the processes before introducing changes in the system) or the selected criteria for differentiating needs to be challenged.
Most probably there are different printforms used for invoices in different countries, so I would prefer to keep the logic for "INVOICE" or "TAX INVOICE" etc. text in the smartform anyway.