I've been on a project like that, and the result was maddening: any page or component template would contain only references to other components and almost no plain HTML tag.
Each time you encountered something like a 'Title' or a 'Button' or a 'FooBarHeader' component, you didn't knew how much Javascript was executed behind each of those, or wether it had any side effects until you looked at the code (and sometime had nasty surprise on components used everywhere).
You also either had to look at its API or modify it to correctly use the web plateform (eg: how do I specify to my 'Button' is of type="button" or of type="submit" ? How do I add some aria attributes ? What if I want to add a 'data' attribute ?).
On top of that, the generated, runtime DOM would look nothing like the design-time template you are changing, which goes against the plateform, again.
And you also ended up with a huge 'components' surface, where this moderately complex (in term of essential complexity) had more than a hundred components, with some basic 'Button' component being monstruous 500+ lines of code under the hood (because of CSS-in-JS), all of it destroying the performance of the page.
On this particular project, I realized that the tag-to-component ratio was less than 1, even maybe closer to 0 than 1. In other words, behind each little <span> visible in the inspector, you had something like 3 to 5 component instances. I've called it "loosing your footing", as you couldn't touch any primitive, drowning in a sea of abstraction.
Somehow, I feel that it's more specific to the 'React' world which is a bit too trigger happy when it come to creating new component.