For me, the biggest reason I use named parameters is when something I'm ’defer’ring can fail. You can set your err return value within your defer only if it's named.
I went into reading this expecting that use case but was saddened it was not mentioned. The use case the author does give is kind of meh, I find it to be harder to understand what is going on than returning as usual, and that's worse than the slight supposed compiler gain is worth.
This is really a Go wart, in my opinion. Go forces you into this pattern, because there's no other way if you want to use defers. So while it's true that it's a legit use of named return values, it's an unfortunate one, too.
I don't do it, but mostly because all I would be doing is logging the error, and if some day it takes me a little longer to root cause some odd file close error, I'll still come out ahead.
I went into reading this expecting that use case but was saddened it was not mentioned. The use case the author does give is kind of meh, I find it to be harder to understand what is going on than returning as usual, and that's worse than the slight supposed compiler gain is worth.