If we are to abstract from particular languages, frameworks and their own interpretations, the abstract software granularity hierarchy is the following:
Product - application, library, service
Module - GUI, core logic, data, etc...
Component - purpose specific collection of objects
Object - collection of primitives
Primitive - numbers, functions, etc...
Plain and simple, the Product is a working collection of connected functional modules.
As the very name implies, the motivation of a Module is modularity. Contrary to what many claim, it does not really imply code reuse. There are many modules which are not really reusable, and don't fit with anything they were not designed to.
It is important to separate different software layers, that makes software much easier to implement and maintain, and should the need to reimplement something like a front end to a different GUI framework, modularity enables that to happen in an easy and safe manner, without breaking code all over the place.
A module encapsulates a collection of components which all serve a common purpose as defined by the module requirements. A module should be self-contained and complete, and while not really usable on its own, it should be able to work in conjunction with any conforming implementation.
In terms of granularity the Component sits between the Module and the Object. The purpose of a component is to put together a collection of general purpose objects to form a purpose specific unit.
As the name implies, unlike the Module, the Component is not "self-contained", it is a part of a larger functional whole.
Objects are the smaller building blocks of components. Objects are collections of primitives and couple them together to serve a lower level, more universal while still somewhat specific purpose.
Primitives are the smallest, simplest and lowest level of software development granularity. It's basically just integer and real numbers and functions/operators, although most languages have their own additional "first class citizens".
There is very little you can do with primitives, and at the same time, it is at a such a low level that you can accomplish practically everything with it. It is just very, very verbose, insanely complicated and impossibly tedious to accomplish while directly working with primitives.
- What's the point of all this?
As already mentioned above, working with primitives directly is an extremely bad idea. Not only because it is impossibly complex, slow and tedious to do for modern day software development, but it is also extremely obtrusive and obstructive to testing and maintenance.
Having all of those conceptual parts incorporated into software development makes it easier, faster, simpler and safer. You don't make a house out of atoms, regardless of how versatile and universal atoms are. That would be an exercise in futility. Your atoms are your primitives, clay is your object, bricks are your components, walls, floor and roof are your modules, assembled together they manifest the final product.
Humans don't really invent anything, we only discover things already out there in the universe, and then copy and apply them to our lives. The same granularity hierarchy is intrinsic to the universe itself, from atoms and even below, to organic molecules, proteins, tissues, organs, organisms and above, reality itself obeys the same principle - combining small, simple, function limited and purpose abstract things into larger, more complex, more functional things and more purpose specific things.
Technically they are all "objects", they are all "components" of software development, they are all "modular" enough to be able to fit together, they are all "products" in the sense that they have been produced and so on...
This is not about terminology or nomenclature, it is about how scaling things up and out affects various aspects of creativity and productivity. And about the importance of not only using all those different levels, but also the importance of not trying to accomplish a goal at the wrong level, which can only be counterproductive.