I think that we need the component:

To be used. We can look at the Google Analytics stats to evaluate the usage. A low usage component either means that we don't have it right yet or that there is a low demand for it.
To match the quality of the core components. It doesn't have to be perfect, none of the core components are and will ever be. It's about nor harming the trust developers have in our solution, to be reliable, so developers can depend on us.
Can it be used as a leverage to incentivize users to upgrade to the latest major? The less fragmented the community is, the better.
Have a low probability of breaking change in the short/medium future. For instance, if we know we want to introduce a new feature that likely require a breaking change. We might as well delay the promotion of it in the core.

A few notes on the current components in the lab.

Tree View: not ready to go into the core, we still miss a few important features, and it's unclear how they will impact the API once implemented
Autocomplete: the frequency of issues is going down, which is a good signal. For features we might want to add, I can think of built-in virtualization, enhanced data fetching integration, pagination. I don't think these features will require breaking changes (they might not even be in the core but enterprise, I have no idea, we will see).
Skeleton: we had a couple of iterations recently. It's unlikely we will need to introduce a breaking change.
Alert: a recent component, but from a complexity standpoint, pretty low.
SpeedDial: it has been around forever, nothing to report.
Rating: the accessibility of this one is challenging to implement. It's also hard to test with our test infrastructure (maybe we would need puppeteer or playwright?). It starts to be in pretty good shape.
Toggle Button: I wonder if we shouldn't merge it with the ButtonGroup component 🤔.

Difference between Lab and Core components? #19448

Description