Well, I had 2 apps written this style in recent memory. One was adapting an existing app with a React frontend and a .NET backend to work in an air-gapped place - we just replaced all the backend calls to calls into the WASM runtime, which did its thing internally.

The other was rearchitecting a microservice-based app, where the .NET server basically only served as middle-man, calling into other various services. Eliminating this middle-man and integrating it into the client allowed us to serve the whole thing statically from CloudFront which massively simplified our infra situation.

I think where .NET shines is writing big, complex applications, for a simple CRUD app where the only thing I do is prod a database, I'd just go with a simple nodejs server.

In my experience, I tend to write all business logic in the back-end, and the front-end's job is mainly just presenting it to the user, so even with fancy SPAs, the bulk of the complexity lives in the back-end.

Keep in mind, that with all the super-duper trimming and size optimization options MS has added to .NET, the runtime is still multiple megabytes, so adding WASM .NET to your typical consumer website isn't super feasible, it's more for these niche use cases.