But it feels awkward for real SPAs - internal applications that have no need for server side rendering.
I get that hydrations value is mainly in SEO and a tiny improvement in initial draw speed, but why would you want it disabled, specifically?
It's pretty much what you already wrote though.
However, when your app is larger or needs to be faster, you want a dedicated backend for your API. Then, you can choose a more secure and more scalable language like C#, Go or Kotlin.
Regarding performance, many SSR advocates (don't forget there's a huge business behind this stuff) don't do the math correctly. It's faster (or as fast) to host a SPA on a CDN and get the data from your backend close to your DB. Let me explain assuming the page containing personal data from the user:
1. The user never visited the site. Getting the SPA from the CDN is very fast. Even if you need to get the JS via a second round trip. Then to get the user data is a much slower second roundtrip to the backend server. With SSR, you also have a first much slower roundtrip to the backend to get your SSR site (maybe even another one for hydration!). Then there's a second slower roundtrip to the server to get the user data. This request is slower than getting the data from a fast API backend in the SPA case. So, if the user never visited the site, you need basically two requests anyway: One for the app another for the data. How else should the backend know, what data to return. With an SPA on a CDN the first request is much faster. I must mention that rendering the SPA is an issue on slow devices. But this is a much smaller problem with Svelte than with React. SEO is probably better with SSR, but no as much as the crawlers are nowadays fast to run the JS.
2. The user has visited the site: The SPA is cached in the browser. Or an eTag validation request goes to the CDN. Very fast. Then, the first relevant request with user auth token goes to the backend to get the user data. With SSR, you get everything with one request. No real world difference there. Both approaches one relevant request. One can argue: Rendering the JS on the client device vs on the Node server. C# or Go backend faster than Next or Sveltekit. But those are not the big numbers.
Now, the big disadvantages of SSR is that you need to run a comparatively slow and not very scalable Node backend. If your app is small, then go for Sveltekit or Next with SSR as the DX is awesome. There's no simpler way to create a fullstack app then Sveltekit. It you have a more complex scenario, most of the time SPA is the way to go.
I get that you've got opinions and like to voice them, but the parent comment didn't say they didn't want to use the node backend whatsoever initially. they only asked how to disable hydration.
IMHO, you'd be better of using Angular or plain svelte for this usecase, as almost all value you get from svelteKIT is the tight backend/frontend integration.
If you don't want that, you're using the wrong tool. But hey, the definition of a hacker is basically "a person that uses a tool for an unintended usecase" (literally: someone that uses an axe to build furniture), and this is called hackernews. To each their own.