I have a pretty general question about the design of Angular web applications. I'm a big fan of writing services. Sometimes I write services that have only utility methods that don't require state at all (think mathematical functions and the like). I feel that even in that case writing injectable services for the utility functions makes sense, since in that case you could swap different varieties of the service easily if you want to change the behavior of your application without having to delete old code inside of your static class.
To give an example: let's say we have a service that computes distances between points. You could just create that service as a plain old class with static methods to do it. But there are numerous ways to compute the distances between points. One might use the simple Euclidean formula, the somewhat more complex Haversine formula etc.
Suppose you'd want to pick the way to do it dynamically so users can choose the desired accuracy/complexity tradeoff. That's going to be a lot of spaghetti if you use a simple static class. On the other hand, it becomes rather simple if you have injectable distance services with a common base class/interface. This is a huge advantage and having state or not is irrelevant.
But still, in the context of web development with Angular this advantage might be tiny for some scenarios, even though it is good design. I was wondering if there is a certain point at which stateless services become so simple that the increase in bundle size or the decrease in (client-side) performance really begins to warrant just turning the service into a simple static class.