The next feature doesn't fit in the current component hierarchy
When you embrace this truth you are less likely to add the 27th optional parameter to some component. You are also more likely to keep coupled components coupled together. You can and should still break down larger components into small components, but don't believe the lie that the semi-arbitrary breakdown of components you just did is the final say in the matter. The next feature might be easiest to implement by completely redesigning your component hierarchy to accomodate interaction where none previously existed.
Too many subtrees, not enough tree slices
The DOM is a tree-like structure. You solve complex problems by solving a bunch of small problems. Naturally, you build components as subtrees and combine them together. But a subtree controls its children. This is not always a good thing.
Components often begin life as a subtree. As it evolves, you don't stop thinking of it as a subtree. This can be an error. If your component has a million optional parameters, it means that component should stop trying to control its children. Push child management up the hierarchy. Turn the component into a tree slice, no longer responsible for the subtree beneath it. The literal parenting analogy is letting the grandparents take care of the children because the parents are doing too much and getting overwhelmed.
A page component is overrated
It is either overrated or incorrectly rated. There is no universal "Page Component" on a living website, except temporarily. Coupled with the fact that you should design features, not pages, it makes more sense to do without a page component.
What are you hoping to achieve with a page component? For me, it's often because I don't want to keep writing the <Header /> component all over the place. But all I've done is replace it with the <Page /> while also limiting my flexibility on a particular page to whatever design constraints I bound all children/slots to within the <Page /> component itself.