Some software bloat is OK

TFA lists maintainability as a benefit of bloat ("modularity, extensibility, code patterns make it easier to maintain"). Completely ignores how bloat harms maintainability by making code unknowable.

Stack enough layers - framework on library on abstraction on dependency - and nobody understands what the system does anymore. Can't hold it in your head. Debugging becomes archaeology through 17 layers of indirection. Features work. Nobody knows why. Nobody dares touch them.

TFA touches this when discussing complexity ("people don't understand how the entire system works"). But treats it as a separate issue. It's not. Bloat creates unknowable systems. Unknowable systems are unmaintainable by definition.

The "developer time is more valuable than CPU cycles" argument falls apart here. You're not saving time. You're moving the cost. The hours you "saved" pulling in that framework? You pay them back with interest every time someone debugs a problem spanning six layers of abstraction they don't understand

I mean there are different kinds of bloats. Some is justifiable, some is not and some is just a symptom of other problems (the last 2 are not mutually exclusive), like mismanagement, incompetence (from management, developers, team leads, etc). This is somewhat similar to cholesterol, there are different types of cholesterol, some might be really bad, some might be harmless, etc.

Bloat (you mean here code duplication?) can be both cause or a symptom of some maintainability problem. It's like a vicious cycle. A spaghetti code mess (not the same thing as bloat) will be prone to future bloat because developers don't know what they are doing. I mean in the bad sense. You can still be not familiar with the entire system but if the code is well organized, is reusable, modular, testable, you can still work relatively comfortably with such code and have little worries of introducing horrible regressions (in a case of a spaghetti code). You can also do refactors much easier. Meanwhile, a badly managed spaghetti code is much less testable, reusable, when developers work with such code, they often don't want to reuse an existing code, because the existing code is already fragile and not reusable. For each feature they prefer to create or duplicate a new function.

This is a vicious cycle, the code is starting to rot, becoming more and more unmaintainable, duplicated, fragile, and, very likely, inefficient. This is what I meant.