A couple of observations:

• This should wait until a decision is made on generics. If the language ends up with generics, this function should work for all element types.
• This is an extra API to avoid a four-line function. I'm not sure if it warrants being in the standard library. In comparison, most other APIs in the strings package are either more complex or fairly optimized.

We have this for sorted arrays: https://golang.org/pkg/sort/#SearchStrings
That doesn't mention case-folding: https://golang.org/pkg/strings/#EqualFold
Is that an oversight?

A strings.Includes(slice, str) could use EqualFold() or equivalent. Might be more complex that way ;-)

The proposal could be directed instead to https://godoc.org/golang.org/x/text/search

It appears evident that a decision was already made to implement generics somehow, but it will be a couple years before anything lands!

At least once a week we need to check that slice of strings includes another string.
It's common code that we have to implement in every project and every package.

Can't you write a library and use it from those projects?

Also note that if the slice is large then that's not the best signature - better to use a map[string]bool instead of a []string.

In any event, this should be held for generics. This is an obvious thing we'd write in a 'slices' packages. (It's the canonical example of generic code, dating back to CLU.)