There are a few assumptions I find troubling here - the new proposals for error handling are not intended to replace existing error handling, merely to supplement it. So where you currently handle errors in a function with if err != nil {dosomething} nothing would change. They are simply intended to cover the cases where people use:

if err != nil {
   return err 
}

or multiple instances of

if err != nil {
   return fmt.Errorf("error at xxx:%s",err) 
}

And make them a little less verbose by allowing you to just use check function() instead. That is all. Errors are still values, and can still be handled individually at the point of failure (unless you choose to group the response), so this is really not a major change to the language.

The article proposes asserts as a replacement for check but this means we still have a proliferation of != nil in most cases, and it would if used liberally mean the error handling was always divorced from the code checking errors. IMO the only time handle{} should be used is for simple annotation of multiple errors, and the restrictions on its use enforcing this are a net benefit, not an unintentional problem. If you need to handle each error differently, use the original error handling.

In terms of concision, one thing I hoped to see but didn't in the Go 2 proposals was to allow gofmt to collapse if err != nil {...} onto one line where it contained only one line of code. This formatting change alone would make the presentation of go code much more compact without any semantic changes.