Not only do you gain performance but I think you gain maintainability and clarity. I value that when you read Go the run-time complexity of operations is very clear. In many other languages you often find O(n) or worse operations that appear to many programs in such a way the uninformed assume they are O(1) operations. In Go that does not happen- almost always what you see is what you get. I will gladly write a few more lines of simple code to gain clarity.
A tuple is just a makeshift struct. Think about it this way: by replacing it with a real struct, you're documenting your code.
This is what it feels like going from a language with tuples, to one without :)
(I would also say "imagine further that you had to do the same whenever you returned multiple values"--but you don't have to imagine ;)
The only thing missing is giving a tuples a name. But if you do that, you should make a struct, or you will forget which field is which and have bugs.
http://play.golang.org/p/XPgHkKCz_D
But you're absolutely right, you trade in some easy expressiveness and lack of boilerplate for better performance and easy concurrency.
But Go is much better about the boilerplate required than most other static/compiled languages, IMO.
Agree re: boilerplate. Much slimmer than Java or C++. And the build times, my God, the build times. It almost makes up for not having a true REPL.
In fact, I started making a list of things Python devs need to know about when switching to Go. It's all a tradeoff, you lose some expressiveness for performance.