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.
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.