This doesn't match my experience at all. In particular, in the case where a small team is working on a series of small projects it can make a lot of sense to split up the components so that any one of the small projects can be built with one or two existing generalized components along with some custom machinery and some glue code to bring it all together. That way development of all of the small products can contribute to some well honed components that get shared by multiple products and development cycles.
It seems like this is not coming up because the most common context of application is one or more teams working on a single large project probably forced to grow as fast as possible because of the funding structure involved. Increasingly, though, there are companies doing software development without the need for focus and scale that is so common to venture capital powered groups.
The major difference is whether the small projects are independent applications that use some shared libraries (what I think you mean by "existing generalized components") or whether the small projects all talk to each other to create a single large application.
If it's the former then you're just talking about refactoring functionality into a shared library, but at the end of the day you're still just building little monoliths. You don't have to worry about most of the problems that come up with microservices.
It seems like this is not coming up because the most common context of application is one or more teams working on a single large project probably forced to grow as fast as possible because of the funding structure involved. Increasingly, though, there are companies doing software development without the need for focus and scale that is so common to venture capital powered groups.