This breaks once you need to update parts of the page without reloading everything.
Nothing prevents the main response from being served as regular HTML and subsequent XHR request for some parts of a page being JSON or some such data format. In fact I bet that sending server-side rendered HTML is faster than sending a full structured page as JSON which has to be decoded, parsed, and then converted to HTML.
We do use a templating engine and separate CSS files, so no, not at all, all static files does not need updating on every change.
> Caching becomes also a challenge and the so does the performance
Not at all, not even on black fridays.
> That would be really hard with a server side rendered html.
Why do you pose that hypothetical when our real-world experience is easy?
This was the original design of REST as applied to the web. It was explicitly designed in such a way that it was forbidden to reload parts of the page. This makes it so that every state has it's own URL and you therefore can link to every state. Deep linking if you wish, for all of the web.
Granted, this requires JavaScript on the front end, but it's a framework that can be shared between different websites, so you're not writing any custom JavaScript for your site.
We eventually trimmed what was returned a bit, but just getting rid of the page transition was 90% of the work.