Although I respect whatever decision you make, please note that there's absolutely nothing I could use as an argument for a license change there, other than "George will work on something else if we don't change it.", which is pretty hard to sell. If you do have valid arguments, please mail me with them so we can have a more focused conversation on actual issues.
And by the way, Qt is also LGPL, so not wanting to link with LGPL software when working on linking with LGPL software is also a curious choice.
To be honest, I probably don't have a better argument than what was already presented because I don't think LGPLv3 with the exception already given is a real practical problem, it is just a problem of companies not wanting to deal with uncertainty. I've run into this quite a bit in the real world, particularly with companies burned by using LGPL on iOS.
Go presents a similar issue to the iOS one in that dynamic linking of Go code to Go code is not an option (at least not without using gccgo), but it is easy to explain this away when using CGO linked code like Qt itself which lives in its own .so/.DLLs because they already understand that the dynamic link barrier shields them from the LGPL issues. But getting them to use Go code with LGPLv3 with exception that will statically link with their own Go code requires some direct involvement from legal/IP to "okay" it. Which could range from being a minor annoyance to a showstopper depending upon the company, in my experience.
And by the way, Qt is also LGPL, so not wanting to link with LGPL software when working on linking with LGPL software is also a curious choice.