When there are plenty of unknowns and you're working solo, you need a very thin layer that lets you craft a prototype quickly and not spend too much time configuring or generally investing a lot because it's something you plan to keep for a short time anyway, or it has a small scope that is never expected to grow. I think this framework kind of fits this model.

In a corporate environment, on the other hand, you're probably building something with the intention to last and then you need something that is established and has rigid interfaces, off-the-shelf components and Stack Overflow activity. Ideally, a framework that can only produce one style of code so that the next person or the next team can pick up.

Another possibility is you're on a budget, a handful, but know-their-way, developers and there is no plan to scale that for the foreseeable future. You want to try out ideas and be able to fail quickly. If you use React and TypeScript for your prototypes, you'll get a sound and solid codebase but also one that also cost you a lot of time. So, if just before the end and a couple of months in you discover you need to do some dramatic changes, you are left with little options and an empty budget.

Each needs to do their research and decide based on their unique requirements and more frameworks = more options, easier to find a fit. In my opinion, use the big frameworks only when you have a clear concept of what you're building. Otherwise, use something that gets the thing done as painlessly as possible.

Edit:

In addition to that, the world changes, and our concept of what is the proper way to build UIs or even what constitutes a good UI changes, as the world and the people change and new technologies emerge. If we aren't exploring ideas at the edge of our undestanding and knowledge, then we'd still be writing <font> tags in our Geocities pages.