Broadly, if you're happy with Django and haven't felt the need to transition to SPA, power to you. This is the case in some industries. It's generally not the case in b2c, though, and if you haven't felt the pain yet then you likely aren't in touch enough with your customers (or you haven't connected the dots).
I don't need to sell you on the concept though I will address your comment in depth.
In general, React (especially with typescript) provides a far better developer experience than Django+Templates. The latter is extremely brittle, difficult to test, difficult to refactor, difficult to organize. The former is robust, typed, testable, easily refactored. It's simply quicker to work with React. And this has quadratic effects on how quickly work gets done: The whole stack is easier to work with, which has gains on every level such as learning pace, testing, including third party libraries, deploying, finding and fixing bugs, ...
The advantages of an SPA are an extension of this. You get to move more logic in this frontend layer. Routing at the frontend layer is mainly a performance thing: You don't get to re-download and re-render your entire page when going from, say, viewing "Produc 1" to viewing "Product 2". The whole structure is the same but the content changes = you should only get to update the content, right? If you handle routing at the frontend level, this is something you can achieve.
But routing in frontend also enables some new things you just cannot easily do without it. For example now it's trendy to have apps that open content (such as a post) which opens in a preview window/drawer (saving your current state), but if you reload the page or share the url, it loads in its own individual view. Why is it trending now? Because SPAs have enabled that behaviour.
GraphQL integration is definitely not something that is required, and in fact in ~30 client projects of this type, I've only ever done it twice, for two people it was actually relevant for.
But: You generally want an API anyway. Writing your frontendbackend communication as an API means you can offer it to your customers as well. It's a good pattern to follow, IMO. And if you're going to have that API, then separating the frontend into an SPA is much easier, because you can use that API to drive all the communication. This makes you a user of it (dogfooding).
As for forms -- Almost all form validation should happen both in the frontend AND in the backend, this is a textbook case of something which should be (mostly) duplicated. The backend MUST validate the input at some layer, lest you end up with security issues. But the frontend SHOULD also validate it, because it's a terrible experience to fill in 15 fields, submit, then see a "please correct the errors below" message with 3 of your fields red, your chosen password gone, the captcha to re-do, and that's if you ever manage to get good errors out of the backend because sometimes it just says "This value is invalid" and you have to manually figure out what's happening there (which for normal people means you'll sometimes hear "your X form didn't work" with zero additional feedback).