I guess it would depend on how you managed your deployments/infrastructure but in general I would say no. In my experience stateless services are all managed differently because they typically need fewer resources and can be scaled more easily. Services that require state tend to have a more hands-on approach since they are usually in the critical path for many other services. Deploying a cookie-cutter service is something where k8s accels so it makes sense to use it for those types of workloads.

What do you define a server as stateless? As... not needing to talk to a filesystem or a cache server or a database?

Just something that takes in API requests (or a cron-like scheduled job) and makes other API calls/does plumbing?

At least in my experience, no.

We used managed services for our stateful stuff which significantly eased the operational burden there. Might be a different story if we looked at doing the absolute minimum cost optimization. However, at least for us, the extra cost of managed services is worth the price.

The yaml tends to be a "one and done" sort of thing. We touch it MAYBE once every 2 months if that.