They would not, they're not even trying to be the same thing.
I get that you don't like RSCs, that's fine you're allowed to have that opinion, but you can't justify it by saying it's a CRUD framework. Apples and oranges.
Can you expand? I'm able to do non-CRUD things in Django just fine too. What's unique about RSC? People have been building production grade, multi page apps with it for almost two decades.
Yes, you can build static pages very easily in any of those frameworks, they're great for that.
The problem is that as soon as your frontend needs to be dynamic, these frameworks do nothing for you. You can do it on your own by using a library like React and making API calls, but that comes with its own set of issues.
RSCs are a way of addressing these issues by making UI and data streaming a core feature of the framework.
With Django you create an API endpoint that queries the database (this already gets complicated if you want types), then on the frontend fetch that endpoint (using some kind of library to manage the request complexity for you), then render that data.
With RSCs you write a server component that grabs data from the database directly and render it.
GraphQL addresses some of the same problems, but has its own set of issues. It's all about tradeoffs.
There's some term confusion. "Static pages" is a different concept -- when there's no code executed on the server, server can only serve static content (no DB naturally), usually from a CDN that can cache responses. We're talking here about dynamic pages.
> a server component that grabs data from the database directly and render it.
Render where?
1. If it renders it to the html content for the browser, it's called "templating", and all the frameworks have been doing it for 20+ years (e.g. ASP, JSP, Jinja).
2. Render to the browser -- it still need to pass that data from server to browser, there's no way around it. And the idea of abstracting that, so the user would not know or care where the code is executed is not new at all. There were multiple attempts, for example see JSF, released on 2001. It burned in flames because you really want and need to know where the code is run.
And there never-ending attempts to at least write in the same language on server and browser, without abstracting the XMLHttpRequest (aka AJAX aka Fetch) layer. For example Node.js -- to use JS on server. Or GWT -- to use Java in browser (died, because you still absolutely want to know how it will be compiled to JS). Now Kotlin compiles to JS. Those are successful to a point. And the ultimate answer to bring all the languages to browser -- WebAssembly.
My point is -- all the attempts aiming to abstract away client-server boundary has been an utterly obvious failure. But if RSC does not aim to abstract it, then it's not different than technologies from 1999, but in Javascript.
I get that you don't like RSCs, that's fine you're allowed to have that opinion, but you can't justify it by saying it's a CRUD framework. Apples and oranges.