While the OP article is indeed unhelpful and unconstructive, it's a pet peeve of mine to see people reference this quote (in the context of any language, not just C++) as a way of deflecting criticism. Not all languages that are used get complaints in equal proportion, and finding the constructive complaints is how we work towards making all languages gradually better.
There are plenty of languages in use that people genuinely enjoy using [1]. A lot of complexity in languages tends to be completely incidental. It's often not inherent in the problem the language solves, and it's just a design decision somebody made based on their aesthetic and experience at the time.
A lot of people seem to take pride in memorizing these quirks, but they're just that. There's nothing fundamentally interesting about them, and they're just mental clutter at the end of the day.
We should strive to have well designed languages that are optimized for developer experience. Accepting poor design decisions just keeps perpetuating the problem.
I can think of only two C++ "quirks" that meet the definition of "just mental clutter; nothing fundamentally interesting about them."
1. Nested templates closing brackets conflicting with `>>` operator, necessitating `> >`. This was fixed in C++ 11.
2. Syntax for declaring an automatic variable conflicts with the syntax for C function type: `Thing mything();`.
Those two certainly seem to be "unforced errors" where the language is simply stepping on its own feet for no good reason, and one of them hasn't even been relevant for over five years.
In all other cases in my experience, investigating the rationale behind a particular quirk has led to a fairly interesting reason; a difference between the heap and the stack, say, or the language giving you the option to not do some work that may be expensive and unnecessary. For example, beginners often are surprised and annoyed that `remove_if()` doesn't actually remove anything and they need to call `erase()`. But most STL algorithms work on a pair of start and end iterators and you can simply work with the new "past-the-end" iterator returned from `remove_if()` allowing you to combine or omit the calls to `erase()`. This is certainly quirky but its not "mental clutter": there actually is a fairly interesting reason for the API being designed this way, rooted in the zero-overhead principle.
In my experience that has been the rule, not the exception - taking the time to understand the "why" behind a given quirk usually results in being forced to admit to yourself, "yes, I see; that is the only way it could have been designed as a zero overhead abstraction. The 'simpler' alternative I had in my head would require some overhead to implement." I think that's the reason why so many people on this thread who have read "The Design and Evolution of C++" change their mind and come away with praise for the language - because it lays bare the logic behind many of those design decisions.
I would be interested to hear which quirks in C++ you view as mental clutter and/or design mistakes. As far as I can tell, most of C++'s usability problems come from it being too carefully designed and too backwards compatible. And after witnessing disasters such as Perl 6, I'm not sure "backwards compatible" is really a "mistake" per se.
Honestly, I haven't used C++ in ages, and I believe you that there great rationalizations for a lot of its behaviors. That's beside the point in my mind though. The end result is a very large and complex language that's very error prone.
C++ goes completely against the principle of least astonishment.There is a huge amount of mental overhead to reading and writing code in it. All that distracts you from the problem you're actually solving and directly translates into long development times, defects, and maintainability nightmares.
I don't think the complexity of the language ultimately justifies the goals it's trying to accomplish.
-- Bjarne Stroustrup [1]
[1] http://www.stroustrup.com/bs_faq.html#really-say-that