The question seems to cover multiple areas at once, including
- Dynamic linking at load time by the OS
- Runtime linking controlled by the application
- Shared libraries, in form of system-wide (or per-user) libraries
- Shared code, either as preloaded by OS or
- Shared code loaded by application when needed, but only loaded once
In any case, all of that was already in use, since the 1970s (*1), in mainframe software. Applications were not only developed in modules and linked to a static binary, but also only partially linked, deferring the final linking to load time. Some OSes did offer link loading as default program start. Here, an executable was not linked at all, but started from a library and linked while loading.
Since the linker was part of the OS runtime, any linking could be done later during program runtime. This included, of course, unloading of modules as well. Underlying this was always some library management system, usually also part of the OS.
In the early days of real memory operating systems there was no difference between shared and not shared, as sharing was just exchanging a memory pointer. With virtual memory this was supplied by the OS. Again, during load and later.
Last but not least were functions where the OS could be made to pre-load certain modules (including whole applications) at startup or by operator command. Quite handy in a multi-user environment with many users using the same applications, like editors, languages or other tools. The main program would be loaded only once at startup. Any user starting 'his' editor, would not load the whole application but only a stub opening local data storage (where the files go) but otherwise run the pre-loaded, shared code.
All of this was developed essentially with the beginning of multi-tasking and multi-user support, as RAM was always too small (*2), putting massive emphasis on space saving.
But the same is true for mainstream micro computers. Sure, OSes started out less sophisticated than mainframes 20 years before, but they soon caught up. This not only includes the mentioned Windows, but also Amiga OS, which was (like Windows) essentially a collection of libraries (*3). Well, and of course various unixoide OSes. Even before that, there was OS/9, offering quite sophisticated ways to share code at runtime. And that's on an 8-bit CPU.
Conclusion: I have a hard time to see the 'not use' of dynamic linking and shared code as implied in the question. The abilities were present all during the 1980s and easy to use. So the assumption about not being offered is wrong.
Looking closely, it seems as if the underlying question is rather why were single-user single-application OSes - like MS-DOS - the main environment used during that time. Right?
It's the classic question why Romans didn't have gas stations: A solution without a need.
Usage in a single-user single-program environment was about one application at a time (*4), which in turn was able to use the whole memory for whatever needed. More often memory was already too small for all functions of that single application, so overlay swapping within itself was needed, not sharing between parallel applications.
Bottom line: Never forget when looking back, that any solution, no matter how helpful it is nowadays, also needs a problem to be solved - often the answer is simply: the problem didn't exist back then.
*1 - Technically even before that, but, like with many other developments, it wasn't until the 1970s that an overall structure was established for generic use.
*2 - In 1970, a machine with 128 KiB was considered large. The largest (civilian) installation in Europe in 1972 was the information system for the 1972 Olympics in Munich, with an unbelievable 2 MiB of online RAM.
*3 - Brian H. may go into more detail.
*4 - Maybe enhanced with a few background helpers.