The biggest purpose for DLLs (or "shared libraries") is when you plan to share your library (go figure) among multiple applications/processes, not multiple developers. Don't confuse something designed to improve programmer efficiency (the use of OOD, well-defined interfaces, code reviews, etc.), with something that was originally designed to address distribution and support of multple programs that want to use the same shared code (VC runtimes are a great example). What is being discussed here is really two different beasties.
First Important Point: Whether you have 1 mammoth DLL or 270 tiny DLLs (like the app I am Lead Dev for does) has nothing to do with the fact that the right way to program large apps is to come up with solid, generic interfaces and code to them. This makes your code more modular, more reusable, and allows you to put more people on the project without breaking each other on a daily basis. This is one of the fundamentals of OOP, and has nothing to do with how you link your stuff. You isolate programmers by having them change encapsulated implementation details. No one cares if the code they are writing ends up in a static library, a dynamic library that gets linked into a DLL, or how many DLLs there are. What they WILL care about is that you had a call yesterday that took 3 parameters, and today it takes 4, and they have to change their code in 150 places. DLL's don't touch this issue at all, for good or bad. The way to enforce proper programming approaches is through solid interface design, and code reviews to make sure people are sticking to it.
Second Important Point: There are many, many, many problems with DLLs, and many complicated systems have been invented to try and resolve them (start your learning journey with the search phrases "Windows COM", and "DLL hell"), and the problems just keep getting more and more complex as the solutions do. Deciding whether you want a bunch of DLLs is really an easy ask: would you rather manage 4 files to distribute, or 400? DLL's serve a purpose, but most of those purposes remain down lower than you need to worry about. VC runtimes make great DLL's. OS code makes great DLL's. Things that a LOT of apps need access to, and need frequent updates - THESE make great DLLs.
Now, let's say you're building a game engine. Unless you plan to a) use that engine in several games; and b) want to be able to update the engine with application X and allow application Y to benefit from the improvements - then you don't need a DLL. In fact, it can cause a lot of problems if you TRY to share a DLL between two different apps like this, when they end up being incompatible (see "DLL hell", referenced above). In general, what really happens is you have version 1 of an engine that you ship with App X. Then when you make App Y, you improve the engine, and ship Engine version 2 with App Y, and so on. If you now try to run App X and it loads Engine 2, well, unless you're World-Class good at forward-design (also known as "psychic", "lucky", or "liar") - then you will have not anticipated something. Then you've either got multiple versions of the same interface all doing different things, or some other kludge - but all to the same effect: different engine code for different apps.
Current best practice is to create a small bootstrapper exe, and then gob as much stuff as makes sense into a single DLL. For a great example of this, see Google Chrome. They have a few DLLs, but most of their code ships in one (relatively) large chrome.dll.
I've come down pretty hard on DLLs, so I'll try to advocate for them at least a little. A great use for DLL's is if you are creating something that you want to sell to someone else, like an SDK. Then, you package your stuff up in a DLL, give them the header files and (hopefully) expanded documentation, and then they can use your code without having access to it, so you can retain the IP.