Statelessness is often a good thing in designs in many ways, performance, reliability, maintainability, operating cost etc.
As a concrete example for a common use case, websites show your user or first name in the top right corner. It's common to put this in a cookie set on login/logout. This avoids querying the user directory service (from the frontend or a different backend service) on every pageload. Security wise it doesn't matter if the user tampers with it, it's a display only thing. (More often than not it's signed anyway, and the cookie contains other things as well.)
Cookies meant to be presented back to a server can be signed and (optionally) encrypted. This is also a very widely used pattern ("cookie secret" is a good search term for concrete implementations in frameworks).
You can't have your cookie and eat it, too; the browser has to store profile information or cookie information either way, so this was never about statelessness. This is about the expectation that user agents will not just consent to server tracking, but carry around papers which will identify themselves to each server so that they can be better tracked.
I'm sorry if I didn't explain what I meant well enough.
I was talking about statelessness on the server side. If you remove cookies from HTTP, you now need a database on the server side.
You also get extra communication (between the client/DB, or the web service/DB), whereas previously the data would've already been available in both (the client has the jar, and the web service gets it in each the request). Turning a local memory read into a network request can be a difficult architectural change.
As a concrete example for a common use case, websites show your user or first name in the top right corner. It's common to put this in a cookie set on login/logout. This avoids querying the user directory service (from the frontend or a different backend service) on every pageload. Security wise it doesn't matter if the user tampers with it, it's a display only thing. (More often than not it's signed anyway, and the cookie contains other things as well.)
Cookies meant to be presented back to a server can be signed and (optionally) encrypted. This is also a very widely used pattern ("cookie secret" is a good search term for concrete implementations in frameworks).