"For years I've tried my damnedest to get away from C. Too simple, too many details to manage, too old and crufty, too low level. I've had intense and torrid love affairs with Java, C++, and Erlang. I've built things I'm proud of with all of them, and yet each has broken my heart. They've made promises they couldn't keep, created cultures that focus on the wrong things, and made devastating tradeoffs that eventually make you suffer painfully. And I keep crawling back to C."

If someone values designing code using the object oriented paradigm (OOP) then it would be expected this same person would use a language that has explicit/stronger support for OOP features (e.g. C++) rather than spending time with a language having weaker support for these features (e.g. ad-hoc simulation of OOP features in C that are rigidly implemented in C++). The issues are if OOP is applicable to a project and if the coder(s) have decent design/knowledge skills to realise any relevance of OOP for the respective coding project.

I find OOP-based design, at the application level, to be a natural stance for dealing with software-coding challenges. I suppose kernel/embedded-level code is another scenario for which my stances may not necessarity be applicable.

C++ does not force a specific form of OOP.
It provides a platform for the production of OOP code according to a style/complexity paradigm maintained/enforced by the coder.

The existence of any deleterious level of "type complexity" and "interface interdependency" would more reflect a poor code design and issues with the associated human software designers/implementers. Sure, the C++ language contains the facilities to produce "deleterious" code but the language itself does not force a person to code in a deleterious fashion. Inadequate design/knowledge skills, in the context of the project, are to blame for this. Sometimes coders get out of their depth (e.g. impatient, temporal-based deadlines, etc.) and create badly designed/implemented code.

The author imparts a "scary" scenario for the existence of "complex types". We should not forget that these "complex" types (i.e. C++ classes,which should not be designed as being difficult to use) manage the complexity of the code base through OOP-related mechanisms such as encapsulation, polymorphism, interface visibility, etc. Instances of C++ classes (i.e. C++ objects) are "fun" to use.

It's about the design.
If "bloated" frameworks/libraries exist and are deemed a "bad" idea, it is not the fault of the language but the fault of the software designer(s).

Sure C++ is not perfect, but I never think about going back to C for my application-level libraries/executables. Minimally, C++ can be used as a "better" C in those procedural-type non-OOP programs.

Anyway, if someone chooses to stick with C ... that's fine.

If someone chooses to stick with C++ ... that's also fine.

At the end of the day we all have differently wired minds that handle complexity in their own special way and it is up to the individual to select a software language they are comfortable with in order to solve the respective software coding challenges.