1,000 components is my standard test for trying out a new UI library.
I recently tried it with Kotlin/Compose. Turned out that everything becomes noticeably slower with so many components, even if the components are in a scroll view and only a few of them are visible.
Displaying so many would require virtualization. No one is going to see a myriad of components all at once anyway.
The slowing down part might be eager computations in partially optimized implementations.
The same way we use pagination on the web, or lazy loading, etc...
But I guess the question is whether that should be a default...
There are a myriad of examples anyone can come up with that require a UI library to simply be fast. For example, perhaps someone wants to implement minesweeper with checkboxes. Or build an "infinite" feed, or a settings panel showing thousands of settings of a system where you can filter with a filter box, etc., etc. You can argue against all of these cases, or you can simply rely on a fast UI library and be done with it.
I recently tried it with Kotlin/Compose. Turned out that everything becomes noticeably slower with so many components, even if the components are in a scroll view and only a few of them are visible.