Nothing wrong of having a website written in ASP/PHP, I would actually argue it is better to render websites server side rather than client side with a JavaScript framework like React. React et al. works better for web apps where the user interacts more with the application rather then just consuming content.
There is no difference between posting a HTML form with a textarea or posting the same text thru an ajax call, the server must validate the payload (perhaps stop evil scripts from being saved at all) and use proper functions to stop SQL injections (prepared statements). When later rendering that saved text that could potentially be a script of some sort, both server side rendering and client side rendering needs to escape outputs to keep the HTML document safe.
Both server side rendering and client side rendering are vulnerable to Cross-site request forgery (CSRF), it can be stopped in both cases with a CSRF token.
Benefit of using client side rendering is that you can use more of the client's CPU to render the document, however it does also mean that the data in the database needs to be transported and handled in the client, which is also a cost.
Another problem with client side rendering is that most thing happens asynchronously, that complicates state handling and rendering. When rendering server side like in PHP you normally do it synchronously which makes it easier to understand and maintain.
Theoretically you can get a smoother navigation with client side rendering, but as long as the server side rendered implementation can send that next document fast enough it should not be a problem.
Modern browser are super fast to render a complete server side rendered HTML, with client side rendering you first need fetch the data needed with ajax and then
construct that HTML document with JavaScript and after that hand it over to the browser. This can be experienced as a slight delay on the first page load.
Old code bases can always have the problem of being badly maintained and non-existing coding convention, no proper error reporting and stuck on an old language version. But you can mitigate that by using a good error reporting tool like Sentry (https://sentry.io/) or similar. When adding new views you could use a micro framework for those new views only and keep the old code as is, Slim framework could be an option for that.
I work with PHP professionally I always opt for server side rendering, it is faster to develop and easier to maintain. Main reason for that is that you already have all data available server side. When doing client side all that data needs to be exposed in an API that you need to design, write and maintain. Things has a tendency to be duplicated on both the server and the client. Many underestimate this cost.
When I need some dynamic updates of a component on the page I use JavaScript to solve that specific case only, not the entire page. To minimize what the JavaScript needs to do (fetch new data, render it to HTML and the put it on the page) it is better to deliver it as HTML fragment from the API endpoint directly rather than JSON, you avoid unnecessary JSON encode/decode step by doing that and you can just take the HTML fragment from the ajax call and insert it onto the page. By doing it like this you can reuse the same backend components when rendering the entire page or just a part of a page. It just how they are delivered to the page that differs. There is even a JavaScript library that can do all that work fetch and swap for you https://htmx.org/
With the htmx library you could also use that for page navigating on the site too if you want it more fluid.