You can also show a proper error page (or continue) through edge functions[1]. They just didn't set any up. So the chances of them also doing so in another framework and caring about being notified is slim.
Nobody is saying everything needs to be serverless. I'm addressing the point that going the traditional route doesn't negate the work required to implement a custom error page and handle rewrites on error.
I think a lot of people do advocate that everything be serverless, but at the very least the industry as a whole defaults to that. You now need a good reason not to deploy bleeding-edge $FRAMEWORK SPAs to serverless edge cloud functions or whatever they're called this month, rather than only using them when it makes sense.
yeah there's a lot of fashion trends that this industry follows and it drives me insane.
by "fashion" I mean new, hot frameworks, architectures, providers, or anything which is chosen because it looks fun or might allow some resumes to be meatier. no one makes solutions for their problems anymore, they make problems for their currently-favorite solution.
I've been guilty of it myself in the past but I'm increasingly getting to a point, especially for side projects that I intend to make a few dollars off of, where I just want to deploy a compiled-language site to a VM and point a domain at it.
1. https://docs.netlify.com/edge-functions/optional-configurati...