It is possible to do some workarounds, but these are still remaining workarounds. Metadata is handy to place additional information, but it still remains fairly static once it is made. I believe metadata is very good for making better UI/tool integration, but ultimately it doesn’t fly back to underlying bindings which is used to feed the item. If you take a look on where metadata is currently used - it is in Alexa, Homekit and UIs, but not in the bindings.
Tags, groups, categories are helpful when we rely on rules, yet again they seem to be static and more useful when it comes to automation, but not pushing data back to binding.
The necessity for additional types comes also from more advanced controllers who are actually able to provided complex structures. I will be able to receive them on the binding side but I will have no chances getting them back to UI as some of them are dynamic, see below.
We can always turn something into String or Map, but I keep asking myself how reliable such solution will be? I believe it solves the problem in some way, but not entirely clear. Our problematic when we take into consideration a BACnet schedule. This is a complex object which can be mapped to a separate Thing, yet some of its properties are are variable size Array() or an overlay type which turns to be an Array under the hood.
So prioritization is one thing the Schedule as a Type or variable length Type accepting something like a tupler/pair (time + command), is a second one.
Turning complex Schedule/Calendar objects into String will result in fairly long values which are difficult to manage. There is a nice example of how to do it with Habpanel made by @nepotu.
Making some attempt to clarify these parts and bring 3rd party type might be beneficiary for multiple cases as it will lead to further unification between UIs and bindings.