I have seen TVARVC used only in 2-3 cases during projects, to be precise, so it is hard to provide examples 
. I was hoping that Jelena could share her views from techno-functional perspective. For my stuff, I used this just once - to maintain the wait time per system for executing a certain set of instructions (to write the result of multiple document modification and creation in a z-log table, it was not 'worth it' to create and maintain another table for something of that sort).
For z-tables you can choose the set of fields that you need for the custom logic, table structure and settings, usually only one team is responsible for maintaining it or at least is controlling what is maintained there. In a previous company I worked in, people insisted not to give authorization to externals for everything in SPRO, only what is really needed for their roles and responsibilities.
Imagine when you have a mixture of internal and external consultants from different teams maintaining some values in the same place ... and usually there is not a single person in the company with a good understanding what all these values influence.
This is why I would go for such option only for very few things with high impact instead of using it for just anything.
Z-tables in addition allow more complex logic, combinations of values from different fields, I believe that it is generally easier to configure and write complex custom logic with z-tables than with variables. I cannot comment on performance impact, since my case was kind of 'special'.
As to the different invoice smartforms - for example countries such as Russia, Belarus, Ukraine have completely different requirements for invoice layouts, not to mention how you fill the data - compared to many EU countries, so they would not use the same forms as, say, Austria. Hellenization is another notable case, where things are not really simple when it comes to document types, printing cancellations and so on.
It is a good approach to avoid excessive hard-coding in printforms, but to expect that you can capture all possible scenarios and influence printout logic for many countries with values from a single z-table, is probably too optimistic. If it is for some relatively simple stuff in the same form (if you can reuse the invoice form in credit/debit memo printout for example), then there are conditions in SMARTFORMS, you can also determine different standard texts based on certain prerequisites. If it is some really complicated logic, which can be reused in other forms, then I would prefer to call a z-FM per country that reads also the country-specific customizing, not just query a generic z-table, which is maintained in addition to it and which everybody forgets about.
I have used z-tables for one logistics form, for example, because we had a requirement to print document items in a special sort order and grouping per product type, packaging, quantity etc., which the logistics key users wanted to define on their own in PRD without modifying the existing master data. In my case z-tables were unavoidable, so the FM read the settings and modified the items for printing purposes.
In all cases, if a country redefines the way it treats a document as tax invoice or invoice or changes the source for determining VAT registration numbers, this implies significant changes in the system setup and master data, so adjusting the smartform text would be the least of my worries.