My experience is the exact opposite.

Frameworks have a very narrow compatibility and accessibility range, and to get the other (often more than) 20% requires extra hackery which has to be bolted onto the framework in ways that were not foreseen by the framework writers.

I've come to believe the difference between framework-lovers and framework-skeptics is that one (larger) group is generally following a well-trodden path and doing only things the framework authors anticipated. Viewing a framework as a common architecture extracted from the experience of writing lots of software, this makes total sense. Most software looks like X, so a framework like X will look like most software.

Those who have problems with frameworks are solving problems that are to some extent novel. Maybe only 10% novel, but that's still enough to feel like the framework is a straitjacket - because everything else is a solved problem and that 10% is the hard bit and the framework just makes it even harder.

Perhaps some of those people could re-examine their problem and achieve it in a different way using the framework, but others couldn't. But to say "if you're not using a framework you're doing it wrong" perhaps exposes a lack of experience with unusual problems, and "all software ends up containing a custom framework" is confusing frameworks with architecture.

One example I can think of was the Play framework.

If you wanted to work with Scala 3 and Play 2.7, you couldn't. You needed to stick with Scala 2.13 to be able to use Play 2.7.

This was more than a year ago. Now we have Play 2.8. Is it compatible with Scala 3 now?

Edit:

I am not entirely sure whether it was possible to make Scala 3 and Play 2.7 work. So my statement above might be partially wrong.

However, I had other dependencies too, which required me to use Scala 2.13.

Consider to downvote this, if you think I made a false statement. I should have looked up the documentation beforehand and not rely on my (past) personal experience/impression at all.

Bad mistake!

Both could be done with libraries.

Things that you (can) put away behind abstractions, layers or wrappers.

I'm the author and tried to convey clearly the difference between libraries and frameworks. Both allow code-reuse, both allow "standing on shoulders". But one allows you to do so with freedom of movement, independence and domain constraints (libraries) whereas the other locks you in, enforces architectures and designs and requires workarounds when your domain-requirements differ from what the framework dictates.