Yeap. I roll my eyes at the people who want to static link everything and think they're somehow better or purer when they're just wasting RAM for nothing.
It is possible and not complicated to implement static linking in a way where the executable file retains the metadata about the component object files and also the OS retains some information about the object files that are already loaded in memory as parts of other executables.
In this case, when loading an executable, the component objects that are already present in memory can be omitted and the references to them in the executable can be adjusted.
While this is not done in the more popular operating systems, due to their preference for the more inefficient dynamic linking, the alternative is still possible.
Moreover, it is impossible to say in general which of static linking and dynamic linking wastes more memory. Static linking will have multiple copies of some code, while dynamic linking will have a lot of unused unreachable code, which is superfluous. Moreover, dynamic linking also has some execution time overhead.
In practice, with the typical bloated dynamic libraries that are available, I have seen much more memory wasted by dynamic linking than by static linking.
When only static linking is used, there is rarely much code duplication besides a small subset of the standard C library, which includes things like the wrappers for system calls and the functions for formatted I/O.
Therefore most of the benefit in reducing memory use from dynamic linking would be achieved with a single dynamic library, which should contain only a subset of libc.
Now, consider the case of a Linux distro with a few thousand binaries. Should a defect be found in a common library, the burden of updating, say, 10,000 servers might rapidly become a headache. In this case, a shared library probably makes sense.
Also, if you want to create extensible software (like a plugin system), dynamic libraries are one of the most expedient and well supported ways to do so. This is not necessarily the traditional use case for shared libs, but it's not uncommon either. And this use case normally doesn't have those versioning problems either (as it leans more to the dynamic side than the shared side).
All that being said- static linking also has its advantages; as you stated, you can be guaranteed that your users are executing the library code you intended and that nothing breaks. It's also faster, because you're not waiting for ld.so to resolve your imports at startup & first use (nit: yes, I know you also can force all resolution to finalize at startup at the expense of slightly longer startup time). Further, you can be sure that someone hasn't hooked your library calls to do something nefarious. The downside, of course, is that you have to re-build and re-deploy your entire application on every library's bugfix/security updates.
As with anything related to computing, everything has tradeoffs. Some tradeoffs may be dealbreakers for your use case, but they might not be for someone else's.
Such as getaddrinfo, or pwent.