By doing it that way I would not spend a large part of my 250 evars on mapping each of the below eventInfo properties to their own eVar and similar events per type
Button Clicked (event)
Tab Clicked (event)
Tab Panel Showed (event)
Tab Panel Hid (event)
List Item Clicked (event)
accordions, forms, hover/touch events etc... imagine how quickly you will run out of eVars and events (evars before events probably, but still).
We need to track a lot of (not just talking a few cta clicks) clicks and other user interaction events all over the UI, so I'm concerned how this will scale and can forsee how we will quickly run out of eVars if we follow that approach.
Which is why I thought it would work well to not use evars for each concrete type of component/element (button, tab, listitem, accordion etc) but breakdown the componentId dimension by another dimension / evar, component resource type. But then, if all components we track is mapped to evar1=componentId we might run into a scalability issue with the 500000 unique evar values and low traffic limitation.
So as I see it for AA to scale well with a pure EDDL based setup, we need A LOT more evars and events at our disposal, or we need that max unique evar limitation to be lifted? Is this just how it is for now, since evars / success events and the Adobe Analytics architecture was not built to support EDDL which is a somewhat new approach to tracking? Are there plans to support EDDL better (what can we expect and a rough ETA, so we might start today, in hopes it will scale when new features / limitations come later this year perhaps) or what am I missing?
Strictly speaking, this isn't a problem with ACDL/EDDL/data layers in general. Data layers serve to act as a "middleman" between your website and your analytics, so that you can track and report data that the website doesn't normally expose. How the data layer's values ultimately get tracked to your analytics is entirely up to you.
Instead, the issue is with your AA setup. I understand that you need to track a lot of data points. So think about it this way:
Do you really need to track all those things that you've listed? What business questions are you hoping to answer with them? Based on that review, could some of those things be dropped from tracking then?
Does each data point really need to be tracked to its own eVar? Could there instead be a "general purpose" eVar that can accept multiple values, yet can return a desired report when paired with the appropriate success event or other metric?
Could you instead take advantage of Classifications? E.g. componentId / componentTitle / componentResourceType, etc sounds like something where you could track componentId to an eVar, then classify that to the other component fields.
Those are some of my suggestions and you don't need to answer them here.