It's a little complicated.
The HTTP I/O needs to switch between textual and binary, because the envelope of an HTTP message is textual while the body of the message is binary. Since this was designed before we implemented bytevectors and binary ports, the only option was to use textual ports and switch their encoding -- and use strings to represent binary data.
The current situation is different. One possible approach would be to wrap a binary socket port in a textual port, use the textual port to generate the envelope, then use the wrapped binary port to handle the body. This would require synchronizing the textual port at appropriate times, but would have the advantage of being pretty straightforward.
Another possibility would be to create the header as a string, then convert it to a bytevector and write the bytevector to the socket port. Reading would be a little more complex since it would be necessary to read bytes, looking for the \r\n\r\n marker that is the end of the header, then translate the header bytes to a string and parse that. I like this a bit better, since it doesn't assume that a textual port has a binary port behind it, which is not part of R7RS. For that reason alone I prefer this approach.
In either case I think it's correct that sockets should be binary ports.