1. Frameworks _are_ libraries with inversion of control.
2. It is harder to write a library than to write a program, because you have to design an API for the calling code. This is a higher order task than just writing a program, because the library has to generalize to all applicable use cases. It is easy to get it wrong (Java Calendar API for example).
3. It is even harder to write a framework, because not only will the framework provide an API to the calling code, it will also take control of the program flow to some degree. If not done correctly, then there will be cases where the calling code could be unable to satisfy some reasonable requirement because they are unable to influence the control flow in that area of the framework. This is an even higher order task than writing a library.
It's akin to the difference between solving a specific problem in math (solve this particular quadratic equation), or solving the whole class of problems at once (derive quadratic formula) or showing that two apparently unrelated problems are actually isomorphic (Galois theory - linking theory of equations to permutations).
The alternative, writing lower level code that you understand, is also bad once scaled out team wide.
It's one thing to write you own bespoke code for everything in your basement, but when scaled out across a team of developers, if there is not a lot of attention paid to consistency of the various parts of the application, then you can get into nightmare codebases that become big balls of mud.
The 10 000 hour commitment only makes you an expert when you spend all those hours deliberately practicing and focusing on improving your performance.
Just engaging in an activity for 10 000 hours does not guarantee expert performance, you need to spend those hours constantly looking for the rough edges in your performance and finding strategies to polish them off.