Client or even frontend https wouldn't have solved the problem in most cases (it is necessary but not sufficient).
The database (or key value store, etc) replication stream is a prime target, as are any backend protocols that let edge data center storage proxy internal requests for core data centers.
a) HTTP/2 is often only supported in encrypted mode (h2). E.g. all browsers only supported the encrypted version, and lots of server side libraries then went the same route.
b) encryption might not be needed, if the services already communicate to each other in a secure environment (e.g. are located on the same host, run in an encrypted/secure network, etc.) In such environments the additonal encryption on HTTP level will only show it's downsides, like lower performance and additional deployment/maintainence concerns (certificate deployments, etc.).
I'm no expert in cloud/microservice environments, so I don't know that the usual configuration is there. But in general I would agree that there are some environments where HTTPS is simply not needed, like using it for localhost IPC on trusted systems.
This is very much untrue, especially if you have multiple datacenters, run in the cloud, or operate out of a colo facility.