It's not a particularly good one unless a static linking exception is included (dylibs on OS X are a pain for no serious benefit, it's not viable at all on Android or iOS).

LGPL is just fine in this regard – you can ship with and link against an LGPL library together with proprietary libraries because the combined result need not be under the LGPL. Whether you link dynamically or statically is irrelevant from a legal perspective.

The parent poster is talking about static linking against a third-party LGPL library, not your own library. In such a case, failing to provide the complete source code, or the original compilation dependencies (.o, .a, .so) and the build chain, is very much against the LGPL.

(Edit: I can't seem to quote the LGPL section 4, so here is a link to it: https://www.gnu.org/licenses/lgpl.html#section4)

There is a massive reluctance in the QT community over this currently -- people want to distribute single-binary applications, and they are told to be careful about doing it.

This exactly. And you straight-up can't do it on Android or iOS.

Except that's not actually true. See, the point of the LGPL is not just that the user has access to the source, but that the user can modify the source and run it. Dynamic linking allows the user this freedom. Static linking generally does not, so unless you provide a way for users to delink your binary then you have to distribute the entire binary as LGPL.