I've deployed gRPC and used the Go bindings extensively, and when I read this article I went "yes! finally!" because this directly touches on two of my chronic pain points.
The Go code it generates from .proto files are the first generated bindings I've seen that use Go generics. I always dreaded needing to look in the stock generated code, but I took a peek at the sample Connect-generated code and it's quite readable. Generics do help; a big part of the cognitive overhead for me in reading the existing bindings is how many "synthetic" types it adds that don't correspond to a named type in the .proto IDL. They have a bidirectional RPC in their example, and its generated Go method has a return type of `*BidiStream[ConverseRequest, ConverseResponse]`. In the grpc-go generated code, that would spawn a named interface type like `ElizaService_ConverseClient`. There's less to wade through.
But for me that's a "nice to have", and the big win I see is the unbundling of gRPC. What I've wanted is just a standard way to do Protobuf-defined RPC over HTTP, preferably one that the developers of API's I use have also adopted. gRPC is that, but when I've deployed it, I've deployed it within a service mesh that provides service discovery, load balancing, circuit breaking, backoff and retry behavior, etc. But gRPC clients include all of that, too, and you can't opt out. The gRPC client will think it has one subchannel open to a single service endpoint, when really it's got a localhost connection to a sidecar proxy providing transparent load balancing. I would just hope things ended up OK.
Distributed systems are complex enough, and the fewer state machines I have to internalize, the better I can understand the rest. Connect removes some of the incidental complexity from something that's meant to be a ubiquitous server-to-server protocol. I'm looking forward to TypeScript and Rust bindings being released!