Redis doesn't support encryption, that's true. But there is literally nothing stopping you from wrapping it's use using an encrypted connection & protecting your host. Nobody is saying your host must be open to unencrypted traffic.
> To my knowledge these are mostly local services
That's a good term for it. Redis is a "mostly local service", that's exactly what their documentation is saying. Just because it listens on a network interface doesn't mean it's intended to be publicly exposed to the internet. That's why they state explicitly that Redis is not intended to be publicly exposed to the internet.
There is a lot of other software running on your computer that makes the same assumption and uses the network stack to communicate with other processes but is not intended for exposure to the internet. Redis isn't doing anything different. Go ahead and run netstat and take note of how many running services have a foreign address listed, and how many do not, of how many are using https and how many aren't.
The funny thing here is I completely agree with the premise of the TLA - I agree that we should be using HTTPS everywhere. But "everywhere" means communication over the internet, and host to host communication inside of complex networks. "Everywhere" in this context does not mean interprocess communication on my computer. Redis is designed to allow interprocess usage, and restricting it's interface to HTTPS would actively harm Redis' design goals and prevent some people from using it they way they want. PostgreSQL is not designed for that kind of usage, it is solving different problems than Redis is.
Even were I to agree with your idea that Redis is designed to be a local service, despite just about everyone using it beyond toy-problem status sticking it on a dedicated caching machine: listen unencrypted on a socket, listen encrypted on a port. Done and done.
I didn't intend for your other comment to get flagged, but since it happened -- I hear you, this is a decent point. Look, I'm not defending what Redis or anyone else is doing, I'm simply saying I understand why, I don't think it's really a super crazy choice, but I understand and agree that it is more dangerous for people that don't read the manual. There are more things they could do to help first-timers be aware of their security. I would imagine that replacing port connections with socket connection would be a pretty big step backwards in terms of ease of use, so I can imagine it'd be hard to convince them to go that way.
> To my knowledge these are mostly local services
That's a good term for it. Redis is a "mostly local service", that's exactly what their documentation is saying. Just because it listens on a network interface doesn't mean it's intended to be publicly exposed to the internet. That's why they state explicitly that Redis is not intended to be publicly exposed to the internet.
There is a lot of other software running on your computer that makes the same assumption and uses the network stack to communicate with other processes but is not intended for exposure to the internet. Redis isn't doing anything different. Go ahead and run netstat and take note of how many running services have a foreign address listed, and how many do not, of how many are using https and how many aren't.
The funny thing here is I completely agree with the premise of the TLA - I agree that we should be using HTTPS everywhere. But "everywhere" means communication over the internet, and host to host communication inside of complex networks. "Everywhere" in this context does not mean interprocess communication on my computer. Redis is designed to allow interprocess usage, and restricting it's interface to HTTPS would actively harm Redis' design goals and prevent some people from using it they way they want. PostgreSQL is not designed for that kind of usage, it is solving different problems than Redis is.