Consider the situation where comparisons in later cases take advantage of guarantees from an earlier, empty case, e.g. this example from net/http/transport.go.

switch {
case cm.proxyURL == nil:
	// Do nothing. Not using a proxy.
case cm.proxyURL.Scheme == "socks5":

If we eliminate the empty case and cm.proxyURL is nil, the next case will trigger a null pointer dereference and a panic.

This is not exclusive to true/false switches. It could happen in switches on a constant:

switch nil {
case x:
case y:
	x.f()
}

or on a variable (swap x and nil)

Not even analysis for comparisons to nil would help, e.g.

s := make([]int, 1)
switch x {
case 1:
case y:
	_ = s[x]

@IronGopher op's example is some special, in which the right operands following case are all different constants.

But the assumed optimization may make programs run slower sometimes,
For example, if the case 1 route is the most frequent branch get executed.

func f(x int) {
	switch x {
	case 1:
	case 2:
		y = 1
	case 3:
		y = 2
	case 4:
		y = 3
	}
}