From my own experience, the text commands are easier to test against, especially its boundaries (inputs to the server) which makes client development significantly easier.
As for HTTP2, isn't that handled by the HTTP server/client implementations and is from the application code the same as HTTP?
As for the HTTP2 portion, the server details would be abstracted out especially with HTTP2 support in Go 1.6. At the time I looked, HTTP2 clients for various languages were still popping up and stabilizing (I think they still are). I didn't want that to be a factor when I was developing clients outside of Go (for example PHP). In addition, an important goal was to develop extremely small clients, where I understood exactly what was going over the wire.
If there are enough direct tooling benefits that HTTP2 can offer, it would be fun to experiment with it as an alternative interface. Funny enough, the first prototype name of the project was "httpq".
Thats not to say a HTTP interface is that much more difficult to add these days.