Everyone seems to be using software frameworks these days and each has its own hype-culture, uniqness-claim, and provides an in-group for its followers. Being somewhat distrustful by nature I developed an aversion against software frameworks over the years. To be a bit more specific, I had to work with Spring, Spring Boot, Angular, Gradle and Reactor. So what I say below is inspired by those and may or may not apply to others.
I make a difference between a software framework and software library. Though the border is a bit blurry, a library is roughly a software framework without all the ugly stuff I mention below.
I contrast this all with a software library providing a well designed API. There is no magic, behaviour is invoked explicitly by calling into the API. Getting started is slightly harder, because some boilerplate code needs to be written to invoke the needed API functionality in the right order. Yet often the boilerplate is not as boilerplate as framework designers assume. There are always those quirky deviations from the assumed and enforced "standard" which force you to fight against framework magic, while the not-quite-boilerplate code you have to write when using a library is all yours to adapt to your needs.
In addition, when leaving a project alone for half a year and coming back, the boilerplate makes explicit what is going on. It can by understood easily again. With a framework, things, hopefully, just happen and you might have forgotten some of the magic details you had researched — until they stop to work or you need to change something.
Using a framework, you literally sell your soul and bet the future of your software on that one framework, since switching would require a complete rewrite. Call it vendor lock-in if you want. But not only with regards to your software. Also with regards to your knowledge and experience. The experience you gather comprises a lot of how to fight or subvert the framework magic to get it your way, not their assumed default way.
In contrast, with a well designed library API, chances are that the next best library covering a similar topic has a similar API. You learn how to use the API, not how to fight against off-by-epsilon magic behaviour. Switching your software to a similar library may actually be possible, while switching away from or to another framework is typically a 100% rewrite.