If the GPL is regarded as inapplicable to dynamic linking, then its purpose is the same as that of the LGPL.
Independently of the linking issue, the GPL prevents redistribution in non-source-code form.
It ensures that users have access to the source code of the covered work, and can modify that code, share the modifications, and build the code to produce a component which replaces the one which the proprietary program uses.
Continuing with the fictitious "Libbash", it means that users can patch or upgrade their "Libbash". My proprietary program will use whatever version they have installed, just like it will use whatever version of /bin/bash they have installed. If I were to statically link "libbash.a" into my program, then there would be a violation: users cannot upgrade or replace that. And, of course, it necessarily must be shipped with my program, being an inseparable part of it, so I cannot avoid redistributing.
Dynamic linking is no different from command line invocation. Having it embroiled in the licensing rhetoric is a pointless mingling of C-and-Unix technology concepts with freedom concepts.
Rather, I think the difference between them hinges on use restrictions. They should both be replaced by a license which is simply silent on the issue: a license which simply forbids the redistribution of the Work in such a way that it is combined into a single image with incompatibly-licensed works, but permits every conceivable use.
By the way, I think even static linking is fair, if the program is distributed as separate images, and only linked as a part of use. (Which is why the LGPL is silly.)
That is to say, suppose we have a "Libbash" library version of Bash. I could ship my program such that when the user installs it and runs its wrapper program, it statically links itself prior to execution. If it finds a "libbash.a" on the system, then it statically links that. Otherwise it falls back on linking to its own "libbash-stub.a" which works by spawning a process. Since I didn't redistribute any part of Bash, I cannot possibly be infringing on any copyright.
According the LGPL (if that were the license), I would be infringing because of the specific linking technology that is identifiable as "static". (Though it is de facto dynamic by being delayed as long as possible, happening on the user's target machine).
Yet note how the user has full rights over "libbash.a". The user can update to a new version or make local modifications, and rebuild this. When the user runs my program, it will notice there is a newer "libbash.a" and re-run the static linking steps.
From the point of view of copyright, I think this scenario may not have the results you want: the user is effectively preparing a derivative work. In fact, your wrapper is.
Preparing a derivative work is an exclusive right of the copyright holder, meaning they can prevent it or place conditions on it. It's not only distribution.
Now, no one (afaik) in the free/open software communities will focus on the user here, they may focus on the wrapper/Libbash writer: if the work you're creating is a derivative work, then it is within the scope of copyright of the parts.
