Web sites tend to have either a lot of static content to serve, or are an interface to database queries of various sorts.
In both of these scenarios, the complexity isn't derived from writing algorithms and data structures that "go wrong" (which static types can help a lot with) but from gluing together the two ends - taking an HTTP request, making it do the thing with the database, and then returning a response. That's the genesis of the LAMP stack - Linux, Apache, MySQL, PHP. Four pieces that just need a little bit of scripting and configuration to turn into an app.
And at the outset, a lot of the benefit of using PHP or Perl was just in having some useful string handling that wouldn't cause a buffer overflow, and being able to test in production by editing the script instead of deploying new binaries. Cheap webhosts would always provide PHP because it kept the deployment so simple. But SQL injection attacks were common and data loss frequent, and a lot of framework features were built on those kinds of challenges - methods of safely handling user input, features for maintaining accounts and login sessions, unit testing, ORM, database migration, and so on. Since they mostly stay in the request-response framing and SQL is leaned on to handle the inner workings of the data, these are things that end up having relatively short, disposable code paths, which if they complexify into something needing more processing, can be offloaded into a fast native-code process that just does the inner loop. I think that approach keeps dynamic languages in the mix - the debugging can be compartmentalized, and so can the bits that need high performance - so it's mostly about features, defaults, deployment. None of the frameworks end up being a perfect fit after the app gets big, but they help start it on a course with some underlying structure. If you go big on the framework you'll have more defaults imposed on you, which can be convenient, but spending a lot of time evaluating them isn't as important as getting the frontend and the database right.
I've been doing some coding with the Symbol blockchain lately and it's served as a helpful comparison, because Symbol has a unique approach that does a lot of framework-like and database-like chores without the use of smart contracts: it persists data, it allows you to update the data's state and review previous versions, it lets you search by various parameters, and, of course, it transfers custody of data between accounts, implements access controls, and allows various kinds of transactions with atomicity. In many cases, the app can exist in client Javascript and access the chain over REST. I started off thinking I would have a Flask app, and now am just writing a single HTML file with everything inlined apart from the SDK used for building transaction data - the framework part of it evaporated. Which is great - fewer dependencies. The limitation is, well, it's a blockchain, and the type of data worth storing on a blockchain is the "wants to be shared widely with an expensive consensus" kind.