This ignores a couple of realities:

1) Most JS developers aren't developing bc they want to have a lovely portfolio of personal projects. They are developing bc they want to be employed doing development. And the VAST majority of jobs out there already have a tech stach selected. And if you're not fluent in that tech stack, you're SOL.

2) A developer who isn't already aware of how to manually hook up a toggle switch likely also does not have the skills to scale a project once the requirements keep piling up. Using a framework at least constrains the direction they go while scaling.

3) Said developer also almost certainly also isn't proficient in the unit- and e2e testing needed to scale a project without introducing too many regressions. Most frameworks do have unit tests already.

4) Most enterprise projects have more requirements than you're probably able to imagine, based on your post. Teams bring in libraries not only because they don't want to write logic that's already out there themselves, but so that they don't have to maintain the code over time. It's often cheaper and easier to let someone else do the bugfixing and QA. There are downsides to it, but often companies find it worth the tradeoff to just use someone else's code when considering the entire lifecycle.