In the case of a proxy, the select(2) call implements the simple predicate "should I read from the client or the server". It turns a pair of coroutines into a single normal routine. The single routine is clearer, perhaps marginally less performant for a single connection, but probably marginally more performant across a large number of connections.
The "asynchronous pattern" thing is a religious canard. Golang devotees are (rightfully) happy to abandon event-structured programs in favor of programs that look like socket tutorial code but perform like event servers. But we're not talking about asynchronous control; we're talking about a synchronous loop. I've noticed this when talking to Golang people: they hear "select" or "poll" and automatically a switch goes off in their head that lights the "BAD!" lamp. I'm not sure that's valid.
Another example, which I gave upthread, was a high-speed port scanner; when I left it to the Golang scheduler to handle the sockets without Golang's timeout idiom, I quickly starved the program of sockets, because of the interaction between timeouts and the scheduler. I pulled select(2) into the program (for that one use only! Just to avoid using Golang timeouts for a simple connect(2) timeout) and the program not only ran quickly but properly handled the socket descriptors.
This isn't a critique of Golang, which I like working with. Rather, I'm criticizing a specific Golang idiom.