There are two competing use cases for web frameworks. In embedded systems you might have one or two users for a web page, and the page exists because you don't want to put a display on the device. That's where a synchronous approach really shines because it's easy to reason about and therefore doesn't break very often. Contrast that with a traditional web site with a backend, frontend, and thousands or millions of users. In that case, async code is easier to reason about because each visitor probably isn't interacting with the same elements of your model at the same time, and if they are you can define how those interactions work and enforce synchronization using the database. So it's not an either/or, but rather two approaches that address totally different situations.

Async is not "definitively a need". It's a fad from browser JS where it is actually needed. Async would not have solved your issue, just delayed it until OOM and that would have make debugging it harder. Case in point.

Usually non-async frameworks spawn some kind of thread so that it never blocks or crashes the main process regardless of what happens to the threads.

I know Go frameworks are usually like that. They spawn green threads and you can write HTTP handlers using simpler sync code to handle requests without worry.