Writing your own framework is almost never a good idea. It is only a good idea for the one writing it because we like tech and we like to show how good we're at building things ourselves. Business wise is the worst mistake ever... unless you're Figma or something like that building something radically special, I don't see how this is a good idea.
You have the first example of this problem in the post itself:
"...We did lost something with this choice. First, we lost compatibility with a couple of tools that we really wanted to use. One of them was storybook, that is a super-nice preview system. We had to develop our own frankenstein to do the same...."
The more your project grows, the more of that you will get. Then one day the people that took this decision leaves the company. And then the new joiners are stuck with an undocumented, failing, spaghetti frankestein mess they have to work on day to day.
And finally...those "few simple" components, will evolve...and sooner than later they won't be neither few neither simple anymore.
It is true that simple apps can usually keep up with trends and documentation of a chosen framework.
But, all too often, the choices in how to use a framework pile up and are lost to the tribal knowledge of a team. This was worse when libraries are pulled in easily to scratch itches for each part of the application without care to the whole.
can you give some examples of poor documentation? most frontend JS frameworks (react included) have friendly, comprehensive documentation.
- https://beta.reactjs.org/learn
> Our choice does not need anyone to learn anything, and one can create a widget in no time!
As someone who made the mistake of writing their own internal framework, I tip my hat to you.
You just created your own framework that people now have to learn. And best of all, the documentation is always going to be less detailed than what you'd get with popular frameworks.