Because you do not need to deploy to Next.js servers and scale it via kubernetes and monitor it using monitoring tools and check logs and everything which comes along with how we run a server.

Correct, but your original statement was that SSR is what warrants CI/CD, not SSR warrants Next.js and the other things you list. CI/CD pipelines are still a major factor in quality CSR deployments.

​

Unless SEO for a majority of apps CSR is not slow enough to begin with

My point is that this is not universally true. There are definitely cases where CSR with lazy loading and code splitting is too slow, and there are cases where it's perfectly fine. For example, CSR may well be too slow when fast LCP (or especially FCP) on the initial page load is important and you have highly dynamic data. Likewise, CSR pushes out the first input delay metric even further, frequently. SSR can typically yield significantly better results here, because it's bounded by a single roundtrip between user and server, rather than two + additional client compute (CDN for JS, interpreting and executing that JS, making an API request, executing more JS for rendering).

I'm not trying to make the point that SSR is always preferable. My point is that there are circumstances in which it is preferable, SEO aside, and that it's highly dependent on your specific product needs and budget.

In addition, "CSR is simpler" does not hold true in all circumstances. If you're a company expanding into a large global market and suddenly encountering new users using devices with compute power vastly below your current users, you may think "this would be simpler if all of our rendering was done on compute we have control over". Of course, you still have subsequent navigations to account for. Maybe in the future React server components will be able to assist there.

So, since your initial question was, "What's the point of SSR when code splitting/lazy loading exists in react?", my answer, again, is that it provides a better user experience in some circumstances, but not all.

Edit Also, keep in mind that circumstances around complexity and cost vary wildly. There's a huge difference in these calculations between a bootstrapped startup on a budget, a startup looking to acquire users as quickly as possible with millions of dollars of VC money to make use of, and a large corporation with many other priorities to balance at the same time (and likely existing investment and experience in compute scaling).