If rapid iteration is more important than performance or cost then you can more easily have a monolithic-ish build system that creates the client and the server from a single code base, or with shared code between them.
If you are trying to upgrade frontenders to be fullstack it’s an easier entry point.
Sometimes the performance characteristics of node actually is useful for serverless since a cold start and a hot start are not very different, closer to a fixed cost just to run a script when compared to something like dotnet which has slow cold starts but fast hot starts. Which is also why it sucks for most server code but on occasion this can be a useful characteristic.
If you want to do serverside rendering with client side hydration then it can be handy to implement the display logic once and run on both the client and the server (eg server side rendering react or vue etc)
Those are a handful of decent reasons but broadly speaking agree, it’s not the best choice if you care about cost and the benefits in the specific cases above are either rare or short lived.
Except really for SSRing with client hydrarion, that’s really the slam dunk case where it’s the more often than not correct choice due to the advantages of not duplicating logic.
The real reason why I often use server side JS is that it’s just faster to write in the first instance if I need to spin something up real quick or for infrequently invoked code where performance and cost don’t really matter. Of course for anything serious it’s a bad choice.