It's true that in the PHP world - which this article focuses on - the norm is to use one of a handful of bloated, one-size-fits all package CMSes. Back in the day, there were hundreds of CMS contenders in the PHP arena; at least today, only a few have survived to maturity (with Drupal being the most mature and the most extensible PHP CMS available, in my opinion).

However, if you look outside of PHP, you'll see that others have already developed a good ecosystem of modular, interchangeable components. I also do a fair bit of Python web dev, and in Python land, the norm is to develop a re-usable component as a stand-alone piece of code, which is managed in its own space (most commonly as a GitHub repo), and which can easily be added as a dependency of other projects using pip (and preferably also listed in a package index such as PyPI).

Python also has its monolithic CMS bogey-men, such as Django, Plone, and TurboGears. But the norm is for devs to make their bits of code available to the world as stand-alone projects, rather than as Django apps or similar.

I know that in other languages, such as Ruby and Node.js, the independent-components-not-CMS-modules approach is also the norm.

We're starting to see this pattern become more mainstream and understood in the PHP world, with Symfony2 components, Composer, Packagist, etc. However, it's still early days.