Ours cloudsql-proxies were on running on GKE so they were not "that bad".

Switching to private ip definitely had the largest impact by far on performance.

If you need very high throughput I can appreciate this advice. Generally though, cloudsql-proxy is fast enough for most use-cases.

What about running it as a sidecar in the backend pods?

This causes some other problems... Kubernetes doesn't do a very good job of treating the sidecar as part of the main container so you will get random disconnects in your app when the proxy is restarted unexpectedly. This is actually why we abandoned it, just to deal with the random hiccups. Hadn't even benchmarked it.