I instead prefer test automation to frameworks for automation. They are both tech debt, but only one of those provides a layer of risk mitigation (regression detection or changes to business requirements). The other provides a substitute for training, experience, and soft skills which suppresses risk realization. Just because the danger is hidden to lower layers does not indicate the danger is gone or avoided. If this were true frameworks would eliminate the need for testing and quality assurance.
The cold hard truth is that most developers are not the genius hackers they fancy themselves to be.
That's the big caveat. Loads of frameworks leave clear issues dead in the water. Your team/predecessors weren't the most clean. Now have fun fixing that one issue working out a framework you can't easily modify or switch out.
Of course that problem isn't unique to frameworks nor inherent to framework rather than social and legal problems.
Usually not for free. Sooner or later there's an API breaking change and you end up spending time reading changelogs trying to figure out how to get your code working again...
You can use frameworks where they fit, and not where they don't. Knowing when to do which takes time and experience, but it is definitely do-able, and better.
Frameworks allow you to update, and maintain your app for free, since others will do it for you. If you do it yourself, you have to do all the work and that's keeping you from adding value elsewhere.
To not use frameworks these days would be objectively stupid unless you're working on extremely low-level things.