Two words: error handling and generics.
Generics I still miss every single day.
But not enough to stop using Go. It's pretty much C with interfaces, a garbage collector, and safety. What more can one wish for?
It just creates the code for you, then you commit it. Easy enough.
Except that it does not provide the same thing. If I provide a package with e.g. a container datatype, I would have to generate for every possible data type that any user wants to put in the container.
Obviously, that is not going to scale.
gen is a good contribution, but it only works for a subset of cases. E.g. I follow a comparable approach in my Java library for finite state dictionaries because Java does not provide generics over primitive types (luckily, that is a closed class). But it's less than ideal.
An analogy would be the "deriving" system in Haskell. It doesn't replace the generics system, it just complements it.
func foo() error { return errors.New("whoa!") }
func bar() {
_ := foo()
// onward!
} try {
foo()
catch {}
There are many situations in which you want errors to go unhandled and bubbled up to some common error handling logic.
Exceptions IMHO are vital. They standardise error handling behaviour across your application and provide flexibility in when, where, and how you handle groups of errors.