What is the benefit of sending to a channel by using select in Go?

In the example directory of Gorilla websocket there is a file called hub.go.

https://github.com/gorilla/websocket/blob/master/examples/chat/hub.go

Here you can find a method on the type hub that does this.

func (h *hub) run() {
	for {
		select {
		case c := <-h.register:
			h.connections[c] = true
		case c := <-h.unregister:
			if _, ok := h.connections[c]; ok {
				delete(h.connections, c)
				close(c.send)
			}
		case m := <-h.broadcast:
			for c := range h.connections {
				select {
				case c.send <- m:
				default:
					close(c.send)
					delete(h.connections, c)
				}
			}
		}
	}
}

Why does it not just send to the c.send channel straight up in the last case like this?

case m := <-h.broadcast:
	for c := range h.connections {
		c.send <- m
	}

It's method of guaranted nonblocking send to channel.
In case of c.send chan can't accept new messages now, a default branch will be executed.
Without select{} block sending to unbuffered or fully filled buffered channel can be blocked.

https://gobyexample.com/non-blocking-channel-operations

// Basic sends and receives on channels are blocking.
// However, we can use `select` with a `default` clause to
// implement _non-blocking_ sends, receives, and even
// non-blocking multi-way `select`s.

package main

import "fmt"

func main() {
    messages := make(chan string)
    //[...]

    // Here's a non-blocking receive. If a value is
    // available on `messages` then `select` will take
    // the `<-messages` `case` with that value. If not
    // it will immediately take the `default` case.
    select {
    case msg := <-messages:
        fmt.Println("received message", msg)
    default:
        fmt.Println("no message received")
    }

    // A non-blocking send works similarly.
    msg := "hi"
    select {
    case messages <- msg:
        fmt.Println("sent message", msg)
    default:
        fmt.Println("no message sent")
    }
    //[...]
}

And to be more clear: for a non-blocking "send", the first case will happen if there is a receiver already waiting for a message. Else it falls back to default